przekompinowanie

No to tak, przejechałem się na własnym sprycie.

Idea: mamy okno i jego Content (nie byle jakie, bo w WPF, znanym szeroko w wąskich kręgach jako WTF). I gdziekolwiek byśmy nie dodali czegoś - ja akurat mam parę CheckBoxów w StackPanelu i kilka serwisów, którym te przestawiają jakieś tam "flagi" - jest dostępne po nazwach w tym sensie bezpośrednio, że jeśli w xaml opis np. okna wygląda tak:

<Window
class="...Okno" // xmlns itp. pierdoły
... >
<StackPanel x:Name="SP" ... >
<CheckBox x:Name="CB" ... />
</StackPanel>
</Window>

to można napisać

Okno w = new Okno();

i np. w konstruktorze mieć linijkę

this.CB.IsChecked = true;

zamiast, jak powinno się zdawać na pierwszy rzut oka (może drugi, jak ktoś "Designera" nadużywa, ja się odrobinę odspawałem na szczęście)

foreach(object child in this.SP.Children)
{
    if(child.GetType() == typeof(CheckBox))
    {
        CheckBox cb = (CheckBox)child;

        if(cb.Name == "CB")
        {
            cb.IsChecked = true;
            break;
        }
    }
}

No i jakby git - od zawsze tak rabiam (górna wersja) i chodzi. A tu nagle chuj, bo: w wyżej wspomnianych serwisach jest w sumie pod 10 sztuk zmiennych bool. A żeby nie rozpuchł się mie kod w .xaml.cs i nie pierdoliło się później przy modyfikacjach (ustawianie czegoś sztuka po sztuce to mordęga, a prowizorka pt. przekazywanie bool[] i konieczność pamiętania o kolejności i liczbie flag w poszczególnych serwisach jednak cuchnie na wiorstę) i jako żem leń, pomyślałem o "refleksji". (Nb. bardzo poliszingliszne przesunięcie członu reflection, właściwe jest oczywiście odbicie). No to chodu - uniwersalny ustawiacz flag w obiektach po prostu mających pola i/lub właściwości (propertisy, jak mawia jeden inżynier) typu bool, rzecz jasna publiczne. Jeśli properties, to oczywiście z { get; set; } w zestawie, żeby wyjątkiem w ryj nie dostać.

W zasadzie jest to tak łatwe, jak plucie pod wiatr: klasa bazowa takich serwisów powinna mieć funkcję pobierającą słownik <string, bool> - nazwa zmiennej i wartość, jaka ma być jej nadana. Piknie. A między nosicielami checkboxów i ustawiaczem niech panuje zmowa, że z nosiciela (contentu, widoku, czy czegokolwiek, gdzie żyją kontrolki - zazwyczaj wewnątrz jakichś kontenerów) zdzieramy stan tylko tych checkboxów, których nazwa zaczyna się od np. CBFlag. I niech pola mają w nazwie Flag, dla kompletu. Nawet parę testów jednostkowych sobie napisałem, podsuwając jakąś wydmuszkową klasę z paroma flagami. Wszystko ładnie-pięknie, zielone ptaszki zamiast czerwonych krzyżyków itp. atrakcje.

Podsuwam stosowną i przetestowaną funkcję do bazowej klasy serwisów, nowy test i... gówno otóż! Bo "refleksja" nichuja nie widzi żadnego CheckBoxa z nazwą zaczynającą się od CBFlag, mimo że wewnątrz .xaml.cs jak najbardziej można używać tych obiektów bezpośrednio j.w. opisano. Tyle że to jakiś wewnętrzny automatyczny wynalazek xaml-a czy WPF-a - wyraźnie niemający nic wspólnego z tym, co dostępne jest "refleksji". No bo skoro Okno wśród pól czy właściwości nie ma CBFlagCośTam,  jasne jest, że nie są to w ten sposób dostępne obiekty; elementarne, Watsonie... Pewnie jakiś wygodny skrót z VisualTree czy czegoś podobnego. Kto wie, może wygodnie byłoby tworzyć sobie taki "wykaz" w locie. Choćby z pomocą klasy anonimowej - nigdy nie używałem, aż sam se wymyśliłem powód... Albo błądzę, tyż możliwe.

Skończyło się na podaniu listy kontenerów trzymających checkboxy. No i o - bangla.

Sry za formatowanie, ale ingerencja ręczna w html i próba omotania kodu stosownymi tagami grozi katastrofą - sprawa ta jest w niniejszym przybytku pojebana prawie jak polska klasa polityczna obecnej doby, a to nie komplement.