Vlákno názorů k článku Historie vývoje GUI (5): systémy Windows 1.0 a GEM od mikro - Aby sme boli fer, tak to, ze sa...

  • Článek je starý, nové názory již nelze přidávat.
  • 12. 10. 2010 9:25

    mikro (neregistrovaný)

    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.

  • 12. 10. 2010 10:13

    ondra.novacisko.cz (neregistrovaný)

    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.

  • 12. 10. 2010 11:35

    Pavel Tišnovský
    Zlatý podporovatel

    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.

  • 12. 10. 2010 11:57

    ondra.novacisko.cz (neregistrovaný)

    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 :-)

  • 12. 10. 2010 12:58

    D.A.Tiger

    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ší