Standardowy NoN standard – Uwaga na Potentatów!

Jak niewiele potrzeba żeby zburzyć człowiekowi światopogląd…. Ile by nie narzekać na molex’y i standard ATX jest to standard. Patrzy się na wtyk czy gniazdo, i wiadomo – to będzie z tym działać.
Tak powinno być.
Jednak w świecie obowiązuje inny standard – NoN Standard.
To on sprawia, że te same gniazda i te same wtyki mają różne wyprowadzenia, często służą do zupełnie różnych rzeczy. Gorzej, doskonale rozpoznawalne kształty połączone ze świetnie identyfikowalnymi kolorami znane z produktów mało znanych marek, których producenci muszą się dopasować do standardów zaczynają znaczyć zupełnie co innego. Przykład? Wszyscy wiedzą, że jak trzymają w ręce zasilacz i jeden z przewodów z niego wyprowadzonych ma kolor żółty to oznacza, że dysponuje stabilizowanym źródłem stałego napięcia +12V, natomiast podobny przewód o czerwonym kolorze izolacji oznacza +5V względem potencjału przewodu czarnego, zaś dla przykładu kolor pomarańczowy symbolizuje wyprowadzenie 3.3V.
I wszystko jest proste.

Jednak uważaj, gdy trzymasz w ręce urządzenie znanego, renomowanego producenta. Wtedy białe naprawdę oznacza czarne, a czarne często oznacza żółte, żeby tak sparafrazować Byłego Pana Premiera.
I właśnie jeden z powszechnie uznanych symboli stabilności totalnie zdestabilizował mój światopogląd. Nie dość, że ułożenie wyprowadzeń pomimo zgodności kształtów niemiało nic wspólnego ze standardem, to jeszcze się okazało że zamiast +12V w żółtym przewodzie było -12V, zaś pomarańczowy oznaczał +12V.

Wiem o tym, że ktoś może mi zarzucić przywiązanie do kolorów, czy też bezmyślne stosowanie jakiegoś schematu.
Ale właśnie po to są standardy, żeby nie musieć się zastanawiać, i wyrwanym z głębokiego snu w sytuacji zagrożenia wiedzieć, co jest co.

Tak więc, pamiętaj Drogi Czytelniku o Zasadzie Ograniczonego Zaufania.

Uwaga na kolejność tworzenia obiektów modyfikujących stan wątków

Sytuacja przedstawiona przez Temporala:
Klasa aplikacji tworząca w funkcji Run() obiekt managera zadań wykonywanych przez system.
Jednym z zadań jest przechwytywanie faktów wciśnięcia klawiszy niezależnie od tego jakie okno jest aktualnie aktywne (mam nadzieję, że Temp wkrótce szerzej opisze rozwiązanie). Istotą jest fakt, że dokonuje się to przez modyfikację zachowania pętli komunikatów aktywowanej przez Application.Run().
Oczywistym jest, że zadanie to jest reprezentowane przez odrębną klasę, której instację tworzy Manger. W tym konstruktorze wykonywane są wszystkie czynności związane ze zmianą zachowania pętli komunikatów (inicjalizacja kolejnego obiektu zarządzającego wywołaniami WinApi z C#). Następnym krokiem jest utworzenie przez Managera wątku uruchamiającego funkcję Start() modułu, która jest zawieszana w pętli komunikatów przez wywołanie Application.Run().
Dodać należy że zmiana zachowania pętli komunikatów dokonywana jest lokalnie dla wątku.

Efektem wykonania niniejszej sekwencji było NIC. Aplikacja się wykonywała, nie prezentując żadnych efektów. Po wielu próbach i stworzeniu dodatkowych dwóch wątków udało się stwierdzić, że system pracuje poprawnie tylko w sytuacji gdy zablokuje w się pętli komunikatów wątek mangera. TeMPOraL zaczął się denerwować, powiedziałem mu „Daj mi tego Kompa, wątki nie znają telepatii, chcę to prześledzić”. On mi na to, to już jest dość złożony projekt, i nie przebiję się. Nie dałem za wygraną, zacząłem od EntryPoint’a. Mniejsza. Po opisie który przytoczyłem i po tytule tego posta już widać, gdzie tkwi problem. Konstruktor obiektu roboczego modyfikował nie tę pętlę komunikatów, którą powinien.

Solution było proste. Przenieść inicjalizację obiektu zarządzającego WinApi do wnętrza funkcji Start(). To pokazuje dlaczego kolejność tworzenia „Wątkowych” obiektów jest bardzo ważna. Dobra rada – uważajcie!