Zamieszczam więc niniejszym skromny instruktarz, który być może kogoś zainspiruje, do kodu kontrolki obecnie dostępu nie posiadam, przedstawię więc bardziej ideę jako propozycje alternatywy dla typowego myślenia o edycji właściwości naszych obiektów.

1. Co to jest refleksja?

Dla tych co wiedzą – przypomnienie (bądź akapit do przeskrolowania), dla pozostałych – kilka podstawowych informacji.

Refleksja to mechanizm pozwalający na pozyskiwanie informacji o klasach, czy kodzie skompilowanych już klas (na przykład właśnie wykonywanego programu, czy też odczytanych przez niego binarek).

W celu użycia refleksji w projekcie .NETowym należy użyć przestrzeń nazw System.Reflection. Dzięki temu będziemy mieli dostęp do podstawowych klas refleksji czyli: Type, MethodInfo, ProprtyInfo, EventInfo, FieldInfo, ConstructorInfo… Każda odpowiada jednemu z elementów tworzących klasy.

Żeby pobrać informacje dotyczące obiektu danej klasy wywołać należy na nim metodę .GetType() dziedziczoną z bazowej klasy Object.

2. Skąd wiemy co wyświetlać?

Metod na pozyskanie interesującej nas informacji jest co najmniej kilka. Możemy pozyskać informacje o klasie wczytując plik binarny i w nim szukając, możemy szukać po nazwie klasy i jej przestrzeni nazw, ale zdecydowanie najłatwiejszym sposobem jest wywołanie wspomnianej powyżej metody GetType() na obiekcie, który nas interesuje.

Co wyświetlać? O tym decydujemy już wyłącznie my! Powinniśmy jednak coś założyć, w tym przykładzie wyświetlać chciałbym wszystkie publiczne Property obiektów.

Skoro już wiemy jak pobrać typ obiektu oraz wiemy co będziemy wyświetlać pozostaje wyłącznie pobrać listę, nie jest to nic trudnego, wystarczy wywołać metodę GetProperties() klasy Type, która zwraca tablicę obiektów PropertyInfo danego typu. Stworzymy więc taki kod:

var type = ob.GetType();
var properties = type.GetProperties();

kod ten nie spełnia jednak naszego założenia, bowiem zwrócone zostaną wszystkie publiczne properties (domyślne działanie nie zwraca prywatnych właściwości!) łącznie z tymi statycznymi (chcemy tylko właściwości obiektu). W celu pozyskania odpowiedniej listy użyć należy przeładowania metody GetProperties wraz z argumentem w postaci wartości enuma BindingFlags (dopuszczając bitowe dodawanie wielu wartości)

var type = ob.GetType();
var properties = type.GetProperties(BindingFlags.Public | BindingFlags.Instance);

Lista gotowa!

3. A co jeżeli jakiegoś pola NIE chcę wyświetlać?

Nie, nie trzeba w takim przypadku robić dziwnych warunków czy aby dane property jest jednym z wykluczonych, czy nie, dużo bardziej uniwersalnym sposobem jest użycie atrybutu. Można działać w 2 strony – stworzyć atrybut informujący o tym, że dane pole powinno być wyświetlane, bądź atrybut informujący o tym, że jego edycja nie jest potrzebna. Pokażę drugie rozwiązanie, jako bardziej ogólne i bardziej do mnie przemawiające, poza tym pozwalające w dalszej drodze edytować wartości obiektów nie należących do danego projektu.

Najpierw klasa atrybutu:

public class HiddenValueAttribute : Attribute
{
}

Po czym umieszczamy atrybut przy Property, którego nie chcemy widzieć:

[HiddenValue]
public string HiddenName { get set }

a teraz modyfikacja naszej metody pobierającej listę do wyświetlenia (dodajemy również jej nazwę):

public IEnumerable<PropertyInfo> GetPropertiesToDisplay(object ob)

{
var type = ob.GetType();
var properties = type.GetProperties(BindingFlags.Public | BindingFlags.Instance);
var returnValue = from PropertyInfo p in properties where p.GetCustomAttributes(typeof(HiddenValueAttribute), true).Length == 0 select p;
}

Jak widać dodana została linijka wyszukująca tylko te PropertyInfo, które wśród swoich atrybutów nie mają tego o typie HiddenValueAttribute, w celu tym użyta zostało użyte zapytanie LINQ wywołujące metodę GetCustomAttributes, która zwraca tablicę atrybutów spełniających warunki. Warunki podawane w argumentach to typ atrybutu (opcjonalny parametr, w drugim przeładowaniu metody nie występuje) oraz czy brać pod uwagę dziedziczone atrybuty.

4. Jak wyświetlać?

Przechodzimy teraz do najistotniejszego punktu – wyświetlanie. Założymy, że wyświetlamy kontrolki na obiekcie klasy Panel o nazwie… panel!

Metoda wyświetlająca kosztować będzie nas najwięcej pracy – tutaj generalnie przewidzieć będziemy musieli wszystkie potencjalnie wyświetlane typy oraz obsługę każdego z nich.

Ale powoli.

Zacznijmy od organizacji naszego panelu, proponuję wyświetlać wartości w wierszach, w każdym etykieta z nazwą i odpowiednia kontrolka dla wartości – taka para dla każdej Property naszego obiektu. Czyli na przykład:

private void CreateControlsForProps(IEnumerable<PropertyInfo> properties, object ob)
{
foreach (var prop in properties)
{
Panel row = new Panel();
row.Dock = DockStyle.Top;
row.Height = 36;

this.panel.Controls.Add(row);
row.Controls.Add(this.GetLabelForProperty(prop));

if (prop.PropertyType == typeof(String))
{
row.Controls.Add(this.GetInputForString(prop));
}
else if (prop.PropertyType == typeof(Int32))
{
row.Controls.Add(this.GetInputForNumber(prop));
}
else if (prop.PropertyType == typeof(Color))
{
row.Controls.Add(this.GetInputForColor(prop));
}
else if (prop.PropertyType.IsEnum)
{
row.Controls.Add(this.GetInputForEnum(prop));
}
else
{
row.Controls.Add(new Label()
{
Text = „Niestety, typu „ + prop.PropertyType.Name + ” jeszcze nie obsługujemy.”,
Left = row.Controls[0].Right + 15,
AutoSize = true,
Anchor = Anchor | AnchorStyles.Right
});
}
}
}

Tak przygotowany kod wystarczy „tylko” uzupełnić o metody tworzące odpowiednie kontrolki dla wprowadzania wartości i etykiety. Podam przykład dla klasy String, dla pozostałych typów odsyłam to pokładów własnej inwencji (nie jest to nic trudnego!):

private Control GetInputForString(PropertyInfo prop)
{
TextBox tb = new TextBox();tb.Left = 75;
tb.Anchor = tb.Anchor | AnchorStyles.Right;
return tb;
}

i dla etykiet:

private Control GetLabelForProperty(PropertyInfo prop)
{
Label l = new Label();
l.Text = prop.Name;
return l;
}

5. A co z wartościami?!

Bardzo dobre pytanie… jak widać… nic. Ale przecież nie po to tworzymy naszą kontrolkę do wyświetlania wartości, żeby wartości nie wyświetlać…

Dlatego konieczna będzie mała modyfikacja powyższego kodu. Zacznijmy od podstaw – jak w ogóle pobrać wartość Property obiektu, którego typu nie znamy z początku, zresztą sami przecież nie wiemy co to za Property (więc rzutowanie, czy wpisywanie nazwy Property po kropce nie jest możliwe)? Nic trudnego, w naszym kodzie mamy już obiekt opisujący Property, potrzebujemy jeszcze obiekt typu, którego dane Property dotyczy – a potem już tylko wywołanie metody GetValue:

prop.GetValue(ob, null);

W naszym kodzie więc potrzebujemy obiektu, którego wartość chcemy pobierać, modyfikacje będą więc następujące:

Metoda tworząca kontrolkę do edycji/wyświetlania wartości:

private Control GetInputForString(PropertyInfo prop, object ob)
{
TextBox tb = new TextBox();
tb.Text = (String)prop.GetValue(ob, null);tb.Left = 75;
tb.Anchor = tb.Anchor | AnchorStyles.Right;
return tb;
}

I co za tym idzie uzupełnienie wywołań w głównej pętli wyświetlającej nasze wartości:

row.Controls.Add(this.GetInputForString(prop, ob));

i podobnie dla wszystkich pozostałych metod dotyczących Property.

6. Ale opis jest brzydki…

Fakt, opisy w tym momencie stanowią nazwy pól w klasie – brak spacji, często niewłaściwy język i skrótowe nazwy niewiele mówią potencjalnemu użytkownikowi. Tutaj z pomocą znowu przyjść nam mogą atrybuty.

Zacznijmy więc od zadeklarowania odpowiedniego (powinien zawierać przeładowany konstruktor oraz musi zawierać Property dla wyświetlanej wartości):

public class VisualDisplayAttribute : Attribute
{
public string VisualDisplay { get; set; }

public VisualDisplayAttribute(string VisualDisplay)
: base()
{
this.VisualDisplay = VisualDisplay;
}
}

Następnie niewygodne Property „ozdabiamy” takim atrybutem:

[VisualDisplay("Tło")]
public Color Background { get; set; }

I modyfikujemy tworzenie etykiety:

private Control GetLabelForProperty(PropertyInfo prop)
{
Label l = new Label();
var attributes = prop.GetCustomAttributes(typeof(VisualDisplayAttribute), true);
if (attributes.Length > 0)
{
l.Text = ((VisualDisplayAttribute)attributes[0]).VisualDisplay;
}
else
{
l.Text = prop.Name;
}
return l;
}

7. Czy można zrobić pola tylko do odczytu? Albo obowiązkowe?

Jak najbardziej – proponowane rozwiązanie to odpowiedni zestaw atrybutów. Np. nowy atrybut ReadOnlyValueAttribute, którego posiadanie przez Property badamy w identyczny sposób jak dla wcześniejszych przykładów i w przypadku znalezienia ustawiamy np. wartość enabled tworzonej kontrolki na false.

Dzięki odpowiedniemu zestawowi atrybutów możemy praktycznie dowolnie sterować całą naszą kontrolką – od możliwości edycji danej wartości, po kolor tła kontrolki, czy jej kontenera – granicą jest chyba tylko nasza wyobraźnia. Faktem jest, że pewne rzeczy dużo łatwiej było by zaprojektować w „tradycyjny” sposób, ustawiając kontrolki w designerze, niż odczytywać wartości z atrybutów pól klasy, po czym przeliczać je na wartości, które „ręcznie” trzeba ustawić w kontrolkach, granicę opłacalności wyznaczyć musimy sobie sami.

8. Zaraz, zaraz… miała być edycja!

I nikt o niej nie zapomniał. Jak łatwo zauważyć – wartości co prawda odczytujemy… ale ich już nie zmieniamy… metod jest kilka, ale wszystkie wymagają jednego – zapamiętania lub pozyskania obiektu PropertyInfo oraz obiektu, który wyświetlamy / edytujemy. Kiedy już owe obiekty mamy, wystarczy nam… jak zwykle jedna linijka… a dokładniej wywołanie metody SetValue klasy PropertyInfo

Zmodyfikujmy raz jeszcze nasz kod – do pól Tag paneli przypiszemy odpowiednie informacje (dla obiektu panel naturalny będzie obiekt na panelu wyświetlany, dla panelu wiersza – PropertyInfo, którego wiersz dotyczy):

private void CreateControlsForProps(IEnumerable<PropertyInfo> properties, object ob)
{
this.panel.Tag = ob;
foreach (var prop in properties)
{
Panel row = new Panel();
row.Tag = prop;
…

Dodajmy obsługę zdarzenia zmiany wartości kontrolki edytującej Property, na przykład:

private Control GetInputForString(PropertyInfo prop, object ob)
{
TextBox tb = new TextBox();
tb.Text = (String)prop.GetValue(ob, null);
tb.Left = 75;
tb.TextChanged += new EventHandler(tb_TextChanged);
return tb;
}

void tb_TextChanged(object sender, EventArgs e)
{
TextBox tb = sender as TextBox;
PropertyInfo prop = tb.Parent.Tag as PropertyInfo;
object ob = tb.Parent.Parent.Tag;

prop.SetValue(ob, tb.Text, null);
}

Gotowe!

Zdaję sobie sprawę, że posługiwanie się polem Tag bywa mętne i trochę utrudnia analizę kodu następcom, ale zostało użyte raczej jako przykład niż wzór – osobiście proponowałbym np. podziedziczyć po panelu i stworzyć klasę panelu wiersza z odpowiednim, dedykowanym Property dla PropertyIfno itp. Takie rozwiązanie będzie dużo bardziej czytelne no i nikt nam wtedy wartości nie nadpisze, gdy stwierdzi, że fajnie by było dla niego przechować coś w Tagu

9.Przecież refleksja jest wolna!

Tak, refleksja działa wolniej niż pobierania i ustawianie wartości „normalnymi” odwołaniami do właściwości obiektów, jednak stworzenie i wyświetlenie jednej kontrolki zajmuje nieporównanie więcej czasu… więc nie stanowi to w tym przypadku żadnego argumentu, ani nie powinno nas to napełniać obawami.

10. Plus i minus, to jedyne co słyszę – czyli kiedy stosować?

Zdecydowanym plusem takiego rozwiązania jest jego elastyczność, można wyświetlić w ten sposób wszystko. Dosłownie. Wystarczy spojrzeć na Visualowe komponenty do edycji obiektów – PropertyGrid’y, które mają bardzo szerokie możliwości, a działają na dokładnie takiej samej zasadzie. Będzie to rozwiązanie szczególnie cenne, kiedy klasy wyświetlane zmieniają się co chwila, albo interfejs powstaje w celu edycji danych, których jeszcze nie znamy.

Kolejnym plusem jest modna „reusability”, jeżeli stworzymy dobrze taką kontrolkę oraz zestaw atrybutów użycie ich w kolejnym projekcie będzie dziecinnie proste – w końcu nie mamy żadnych odwołań do klas encji biznesowych, czy jakichkolwiek innych klas, które chcemy wyświetlać.

Oczywiście są i minusy…
M.in. dużo cięższe debugowanie wymuszone przez użytą refleksję.

Brak możliwości podejrzenia jak wygląda kontrolka w trybie design, jedyna możliwość to uruchomienie aplikacji na przykładowych danych.

Monotonność interfejsu i dużo trudniejsze modyfikacje wyglądu kontrolek pod konkretne Propery. Bez napracowania się nad atrybutami i ich interpretacją każde użycie kontrolki do wyświetlania danych wyglądać będzie identycznie.

Można zadać sobie pytanie po co tak się męczyć? przecież są wspomniane już PropertyGrid’y, są dobre do edycji danych Gridy. Ciężko temu argumentowi zaprzeczyć, to prawda. Tym niemniej tych gridów nie zmodyfikujemy, nie powiemy im co mają wyświetlać, a co nie w tak łatwy sposób itp. To rozwiązanie da nam pełną dowolność, której być może będziemy potrzebować.

Ułatwiłoby to logowanie wszystkiego, co zachodzi w aplikacji. Wywołując metodę:

public void CountPrice(int bar, string baz)
{

}

chciałbym otrzymać w logach wpis:

Method’s Foo arguments >> bar: 1, baz: zzz

Najpierw spróbowałem za pomocą metody GetParameters klasy MethodInfo. Zwrócone obiekty typu ParameterInfo zawierają jednak tylko informacje o typach parametrów – nie mają wartości tych parametrów w czasie wykonywania kodu.

Moim celem było stworzenie metody, którą mógłbym użyć do pobrania sformatowanej informacji o parametrach metody – na przykład w celu zalogowania ich. Załóżmy dla prostoty testowania, że nasza metoda Foo będzie zwracała sformatowany napis z jej parametrami i ich wartościami.

Pierwsza wersja:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return LogingHelpers.GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments()
  {
    //TODO tutaj magia :-)
    return "";
  }
}

Niestety – z taką składnią nie udało mi się. Z kontekstu LoggingHelpers.GetMethodArguments nie da się (lub nadal nie potrafię :-) ) dostać się do parametrów metody wywołującej. Działająca składnia jest nieco inna i odrobinę mniej wygodna:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return GetMethodArguments(() => bar, () => baz);
  }

  public static string NoParameters()
  {
    return GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments(params Func<object>[] expr)
  {
    //TODO tutaj magia, ujawnione już za chwilę!
    return "";
  }
}

Ale najpierw test z wykorzystaniem NUnit.

    using NUnit.Framework;
    using NUnit.Framework.SyntaxHelpers;

    [TestFixture]
    public class LoggingTests
    {

        [Test]
        public void TwoParametersCorrectlyFormatted
        {
            string parameterNamesAndValues = TestClass.Foo(1, "zzz");
            Assert.That(parameterNamesAndValues, Is.EqualTo("Method's Foo arguments >> bar: 1, baz: zzz");
        }

        [Test]
        public void NoParametersCorrectlyFormatted
        {
            string noParameters = TestClass.NoParameters();
            Assert.That(noParameters, Is.EqualTo("Method's Foo arguments >> No arguments.");
        }
    }

Odpalamy testy, który oczywiście nie przechodzą.

Żeby testy zadziałały, nasza klasa LoggingHelpers wraz z metodą GetMethodParameters może wyglądać tak:

using System;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.CompilerServices;

public class LoggingHelpers
{
    public static string GetMethodParameters(params Func<object>[] expr)
    {
      // Pobieramy nazwę metody.
      string methodname = new StackFrame(1).GetMethod().Name;

      // wstępne formatowanie wynikowego napisu:
      string logmessage = "Method's " + methodname + " arguments >> ";

      // Tablica wyrażeń lambda jest pusta
      if (expr.Length == 0)
      {
        logmessage += "No arguments.";
      }
      else
      {
        try
        {
          // dla każdego Expression
          foreach (var par in expr)
          {
            // Zaawansowane sztuczki. Za pomocą MSIL znajdujemy informacje o Expression
            byte[] il = par.Method.GetMethodBody().GetILAsByteArray();

            // bajty 2-6 oznaczają uchwyt do naszych parametrów
            int fieldHandle = BitConverter.ToInt32(il, 2);

            // pobieramy FieldInfo tego parametru
            FieldInfo field = par.Target.GetType().Module.ResolveField(fieldHandle);

            // Formatujemy ostatecznie napis dla tego parametru.
            // Nazwę parametru uzyskujemy z FieldInfo, natomiast wartość wykonując przekazane Expression.
            logmessage += string.Format("{0}: {1}. ", field.Name, par() ?? "@null");
          }
        }
        catch
        {
        // Ignorujemy błędy - nic nie jest gorsze od doskonale działającej logiki aplikacji, która wywala się na narzędziach do logowania :-)
        // Tego typu try-catch to zła praktyka w aplikacji! W tym miejscu jest to stosowne, ale przestrzegam przed nadużywaniem "zjadania" wyjątków.

          logmessage += " FAILED reading arguments.";
        }
      }
    }
}

Klasa do wykorzystania w aplikacji.

W kolejnej notce pokażę, jak to spiąć z log4net.