Taki tam durny projekt sobie ubzdurałem i chce się skonsultować bo jak wiecie samemu czasem trudno błędy w genialnym pomyśle zobaczyć.

Ideą jest zrobienie biblioteki z prostym GUI i podstawową obsługą I/O tak by kod wykorzystujący bibliotekę nie wymagał zmian przy zmianie platformy. If'ki dla kompilatora albo osobna biblioteka, zależy co będzie wygodniejsze dla uzyskania celu.

Jest sobie kod natywny pod platofrmę (testbed na Winiaczu) który wyciąga i opakowuje ładnie funkcje api systemu: rysowanie prymitywów, input/output i może stos TCP. Taki tam badziew żeby to była jedyna część kodu zależna od platformy.
Na to jest narzucony prosty Framework który na wcześniej opakowanych metodach tworzy podstawowe elementy GUI, jakiś button i textbox, oraz zarządza kolejką komunikatów.
Całość w cepie, bo idzie go skompilować na wszystko, popakowane w klasy umożliwiające dziedziczenie (np Control->Button->Image Button->Custom Button czyli nic nowego).

Kodzik aplikacji robi App.Run(Window) i sobie będzie lecieć pętelka obsługująca całe GUI wykorzystując podany obiekt jako okno główne.

I tu nachodzi pytanie, jak poukładać wnętrzności.

Potrzebna jest oczywiście obsługa danych wejściowych, mysza i kreatura wystarczy, żaden problem, brać od systemu i ładnie upakować w ujednolicony format.

Następnie potrzeba utworzyć obsługę zdarzeń całego GUI.

Nie chcę komplikować zbędnie projektu więc zdarzenia postanowiłem ograniczyć do OnDraw, OnMouseClick/Down/Up, OnKeyClick/Down/Up, powinno wystarczyć do podstawowego GUI, chyba że się mylę więc jak o czymś głupio zapomniałem nie bójcie się mi rzucić tego w ekran.
OnClick będzie po prostu odpalane po OnUp, niby zbędny ale "ręczne" wywoływanie On***Click jest wygodne przy wredniejszym GUI.

Następnie potrzebne będzie obsłużenie zdarzeń.

Jako że chcę mieć hierarchiczność kontrolek (parent->child) komunikaty muszą zostać obsłużone przez parenta i ewentualnie podane do childów.
Pomysłem moim jest limitowanie OnDraw prostym sprawdzeniem Child.Visible, od razu odetnie to kontrolki zawierające się w niewidzialnej.
Dla kreatury potrzebne by było coś w stylu KeyPreview z Delphi czy WinForms bo kreatura inaczej będzie lecieć tylko do kontrolki z Focusem.

No to pytanie pierwsze:

  1. Jak operować Focusem
    a) Sam Framework sprawdzi gdzie nastąpił klik i jeśli Enable==true to przestawi Focus
    wady:
    -wymaga przeszukiwania drzewa kontrolek w celu sprawdzania zajmowanych obszarów lub trzymania i ciągłego odświeżania listy widocznych regionów.
    zalety:
    -obsługiwane przez system, żadne dziedziczenie nie schrzani obsługi focusa.
    b) Podstawowa klasa Control będzie reagować na klik i się sama ustawi jako aktywną.
    wady:
    -trzeba pilnować żeby na każdym stopniu dziedziczenia odpalać obsługę focusa
    -odseparowanie obsługi focusa od klika uniemożliwi nadpisanie obsługi focusa, a to się czasem może przydać
    zalety:
    -wpięcie się w kolejkę komunikatów, jedno przeszukiwanie drzewa zamiast dwóch

Następnie by trzeba odpalić Draw i podać Input.

Pytanie kolejne
2. Draw przed Inputem czy po Inpucie? Nie mogę się zdecydować ale myślę że po Inpucie będzie lepiej bo można zmienić wygląd od razu po kliku.

  1. Czy jest jakiś sens optymalizować drzewo kontrolek poza sprawdzanie Visible i Enabled?

  2. Przy przekazywaniu wciśniętych klawiszy do kontrolki z fokusem w jaki sposób obsłużyć KeyPreview:

  • KeyPreiview przed czy po kontrolce z fokusem?
  • Czy jest jakaś wada przeszukiwania drzewa od aktywnej kontrolki w górę po parentach? Logicznym wydaje mi się by KeyPreview nastąpił najpierw dla kontrolki najstarszej, a przeszukiwanie od dziecka odwróci kolejność i jeśli będę chciał ją zachować potrzebne będzie zebranie znalezionych parentów z KeyPreview i obsłużenie ich od najstarszego w dół po zakończeniu przeszukiwania.

By uniknąć zbędnych rozmów zaznaczę że celem projektu jest wykonanie projektu, sztuka dla sztuki, jestem całkowicie świadom że jest on bez przyszłości.