Názory k článku
Historie vývoje GUI (5): systémy Windows 1.0 a GEM

Aby sme boli fer, tak to, ze sa pri programovani pod Windows museli udalosti spracovavat rucne zase nie je az tak nieco tragicke/vynimocne -- programovanie poD GEMom je prakticky o tom istom, jedna while( !quit ) slucka a v nej citanie sprav a rucna obsluha, vratane kodu na prekreslovanie / prekryvanie obsahu.

Message pump píšu do dnes ručně. Zvlášť u malých projektů, kde těch zpráv, které obsluhuju je tak pět na každé okno, na což se nevyplatí nasazovat nějaký šílený framework.

Objektové programování v tom hodně pomáhá, právě třeba v možnosti routovat zprávy na příslušné instance oken (objektů). Nicméně každé okno má funkci

LRESULT winProc(UINT msg, WPARAM wParam, LPARAM lParam);

Jo, chybí tam HWND hWnd, protože to zpracuje už ten router. Dědičnost, volání předka, a podobné vymožnosti C++ pak umožňují krásně dědit takto napsané ovládací prvky - prostě prostým "naháknutím se" na tento jednoduchý dispatcher.

Jasne, pro aplikace, ktere maji jednoduche GUI je mozne WinAPI pouzivat primo (taky jsem si s tim uzil sve, ale to bylo jeste ciste Cecko), ale napriklad pro slozitejsi dialog to vede ke kodu s milionem vetvi ve switch, coz neni moc prehledne.

Zase bych to s těma milionama nepřeháněl. Chce to nějakou strukturu :-)

Je fakt, že implementovat v dialogu takový ListView nebo TreeView, to je něco, tam ani tak nejde o switche, ale i o vlastní vkládání prvků přes zprávy LVITEM, TVITEM, HTREEITEM, atd.

Ty switche jsou důsledkem toho, že Windows pojaly parent okno (dialog) zároveň jako "model" (v architektuře MVC) - takže ty hromady notifikací, změn v controlerech zasílaných na parent okno je hafo. Nejprve je tedy potřeba všechny zprávy směřující ze všech ovládacích prvnků přesměrovat do patřičných modelů... a těch větví tam už zůstane minimum.

Tohle je bohužel nedomyšlenost celého konceptu vyžadující různé hacky. Tak například model je spojen s view, ale požadavky view na model vyřizuje parent okno, který kolikrát nemusí o nějakém modelu nic vědět. MFC ukazuje řešení v podobě "reflected" zpráv, kdy parent okno reflektuje tyhle zprávy zpět do poděděného ovládacího prvku, jako jejich výchozí implementaci (pokud nejsou zpracovány dříve). Předpokládá, že specializovaná verze controleru si to dál přeroutuje na model.

Jiné řešení je napsat si ovládací prvky sám :-)

Tohle podle mě dobře řeší systém zpráv Fox Toolkitu. Přijde mě to z hlediska uživatele knihovny jednodušší a flexibilnější

Když tady byla zmínka o "Ventura Publisher" a GEM, tak jsem si vzpomněl na něco podobného s Windows. Setkal jsem se s DOSovými aplikacemi, které používaly jakousi knihovnu, která měla skoro stejné API jako Windows, ale linkovala se přímo k DOSovému programu. Viděl jsem v tom i nějaké aplikace. Jeden texťák ve kterém se v dalších oknech otvírala kalkulačka a jednoduchý file manager. Vipadalo to úplně jako Windows. Dokonce jsme v tom také chtěli dělat nějaké softy, ale sešlo z toho. Pamatuji si, že se to jmenovalo WinTNT, nebo tak nějak.
Ví o těchto "pseudo windows" někdo něco bližšího ?

TCXL ?
Jeden zdroják šlo přeložit jako DOS i jako Windows program ale já jsem v tom psal jen DOS programy.
Možná bych to ještě našel - kdyžtak jmeno at prijmeni dot cz