Probublávání událostí v GUI

[Solid.Sn]

Ahoj,

snažím se v Direct3D splácat uživatelské rozhraní obsahující tradiční objekty jako je Form, TabControl, Panel, Button, Label, CheckBox, RadioButton, Edit a podobně.

Dostal jsem se ale k problému. Nedaří se mi vymyslet nějaký funkční způsob probublávání zpráv (udáslostí, nebo jak to nazvat) až k určitým objektům, které tuto událost zpracují (tzn. kliknutí myší na určité tlačítko, stisknutí klávesy v editu a podobně...) a stejně tak se mi i nedaří najít nějaký popis toho, jak tohle funguje například ve WINAPI (předpokládám, že to chce hledat jen nějaké správné klíčové slovo, ale prostě jsem nic použitelného nenašel).

Chtěl bych vás proto poprosit o radu, díky...

[Matasx]

Přesně asi nechápu otázku... ale normálně přes události (events) ne? OnClick, OnDoubleClick ... atp. což jsou vlastně delegáty ke kterým uživatel (programátor) přiřadí vlastní funkce.

[Quiark]

No pokud to budeš chtít udělat super obecně a flexibilně, tak se pěkně zapotíš. Pokud ale budeš dělat hru s normálním GUI, tak si většinou vystačíš s posíláním vstupu z klávesnice aktuálně aktivnímu objektu (focus) a události myši objektu pod myší. Případně si každý objekt zaregistruje, co chce dostávat a pak to budou dostávat všichni zaregistrovaná (a musí si pohlídat, jestli se jich to týká).

Ve WinAPI to funguje víceméně podobně a navíc tam jsou pak extra cesty na ty složitější případy (jako například klávesové zkratky). Nějaký konkrétní článek, který by to shrnoval ti nedám, ale když začneš třeba od dokumentace WM_MOUSEMOVE, třeba se něco dozvíš Dál se můžeš inspirovat event modelem v DOM u HTML, tam je to taky krásně složité
_________________
Mám strach

[Ladis]

Něco podobného jsem si zkusil před mnoha lety, akorát to bylo v SDL + OpenGL. Ovládací prvky maj pořadí pro tabování podle pořadí vytvoření (ale lze bez problému upravit, aby šlo za běhu měnit). V jednu chvíli je jeden control aktivní (zaktivní se tabnutím na něj nebo kliknutím myši). Ten aktivní dostává vstup z klávesnice, vstup z myši dostává ten pod kurzorem myši (každý prvek má obdélníkovou oblast, popisující kde je, stačí je tedy projít od posledního - toho nejvíc nahoře - a testovat, jestli pozice kurzoru patří do něj). Reakce na události mám ukazateli na funkce objektů, takže si přiřadím svoji funkci tomu controlu na vybranou událost, např. tlačítku na kliknutí. Mám tam i takovou vychytávku, že když stiskneš tlačítko, tak se zmáčkne, ale událost stisknutí se zavolá, až když myš pustíš, a můžeš za zmáčknuté myši kurzorem vyjet ven, aby se tlačítko nezmáčklo (přesně jako ve Windows a spol.). Zdrojáky zde - myslím, že zatím to umí jen labely, textboxy a buttony (pro princip stačí, další controly jsou už ve stejném stylu; je tam i binárka (tfoclient.exe), kde můžeš vidět, jak ty frmuláře vypadaj; ještě detail, ten kód je pro celoobrazovkovou hru, takže formuláře tam nazývám obrazovky - screens).
_________________
Award-winning game developer

[Solid.Sn]

Ahoj,

po delší době jsem se vrátil k návrhu GUI a chtěl bych se zeptat spíše na takovou teoretickou otázku.

Prostudoval jsem si W3C specifikace tohoto problému a nezdá se mi úplně ideální probublávání událostí například u pozicovaných elementů (i když je to jasné a logické).

Probublávání OnClick u nepozicovaných elementů není co řešit - probublávání probíhá tak, že se prostě dostane událost od cíle až ke kořenovému elementu přes svoje předky/potomky (v příkladě Button1 a Button2). Pokud se ale element (Button3) napozicuje tak, že je mimo svého předka a navíc ještě přes jiné elementy, přišlo by mi použitelnější, aby událost probublala přes elementy "pod kurzorem" (v době kliknutí), né přes svoje předky (které jsou v úvedeném příkladu mimo Button3).

Má smysl toto řešit, nebo je návrh W3C nějakou vlastností použitelnější nebo správnější?

Díky za názory

[tomkis]

[Solid.Sn]

[frca]

Ja bych pouzil takovy pristup, ze bych posilal zpravy vsem prvkum a zpracoval by si je jen ten, ktery by mel nejvyssi prioritu. Ta by se musela nejak rozumne kazdemu prvku nastavit dopredu (asi nejvyssi tem, ktere jsou v nejvrchnejsi vrstve). Kazdy typ zpravy by mel priority vlastni a napr. nulova (== nejnizsi) priorita by znamenala, ze prvku zprava vubec nedojde (protoze ji neni schopny zpracovat.
_________________
www.FRANTICWARE.com

[Solid.Sn]

Nad tím jsem taky přemýšlel... napadlo mě, rozeslat zprávu všem, ty elementy, které můžou / smí na zprávu reagovat událostí se ke zprávě "přihlásí" s nějakou prioritou a následně bude probublávání probíhat ne stylem od cíle přes předky ke kořenu ale právě od nejvyšší priority z přihlášených elementů k nějnižší.

Zpráva tedy projde všechny elementy (čehož se trochu bojím, v případě, že může jít o stovky/tisíce elementů), při průchodu se vytvoří fronta zájemců a po ukončení průchodu se spustí události na tuto zprávu dle priority postupně u všech přihlášených.

[Solid.Sn]

Implementoval jsem události v GUI velmi podobně jak to popisuje W3C.
Zkouším nyní Drag&Drop a přišel jsem na problém s MouseMove.

Došel jsem ale v obou případech na stejnou věc, jak v JS, tak v mé implementaci (která je s velmi podobná JavaScriptovým událostem) dochází při takto implementovaném Drag&Drop ke stejnému problému.

Pokud kliknete na "titulek okna", spustí se OnMouseDown, která nastaví příznak lock na 1. Pokud tlačítko pustíte OnMouseUp, pak se příznak nastaví na nulu. Je-li příznak lock nastaven na 1, pak se okno při OnMouseMove na titulku okna posunuje na souřadnice dané kurzorem. K chybě dochází v případě, že táhnete kurzorem rychle. Zpráva WM_MOUSEMOVE příjde najednou v době, kdy je kurzor už jakoby mimo titulek okna a tím se zruší příznak a přeruší se táhnutí.

Napadá mě několik způsobů jak toto vyřešit. Například OnMouseMove (V JS na element Body, v mé implementaci na něco podobného ). Ale to mi již příjde jako obcházení tohoto problému špatným způsobem.

Také by to šlo vyřešit tak, že při situaci, kdy dojde k OnMouseDown a následně OnMouseMove na jednom elementu, pak nechat události procházet jen na element, nad kterým bylo tlačítko stlačeno, ale také to není v pořádku a zase se tím znemožní jiné věci.

[b]Pro představu přikládám ukázku http://www.uloz.to/10250048/gui-exe (vypnout se to dá Alt+F4 nebo kliknutím na červené tlačítko v titulku toho, co by mělo být okno )

Děkuji za případné tipy

EDIT:

Zde je funkční způsob (http://www.uloz.to/10251558/gui-exe) řešený tak, že mousemove pohyb odchytává při propagaci události v kořenovém elementu (dejme tomu něco jako plocha) a jelikož se kurzor mimo tento element nedostane (když neberu v úvahu vyjetí z okna), tak to funguje. (Díval jsem se a většinou se to takhle řeší právě i v JS - document nebo body.)

Na druhou stranu, dejme tomu, že budu mít posuvník, nebo nějaký track bar. Pak mi příjde odchytávání mousemove při propagaci události v kořenovém elementu pro tyto komponenty jako nesmysl.

[Solid.Sn]

Ještě se zkusím zeptat jinak.

Jaký způsob šiření MouseMove události je podle Vás použitelnější / správnější...?

Zkoušel jsem MouseMove na Windows Forms Aplikaci a dopadlo to takto:

Pokud nedojde ke kliknutí na tlačítko, chodí MouseMove zpráva prvku, který je pod kurzorem. Je-li tedy pod kurzorem button, zasílá se zpráva tomuto prvku, je-li pod kurzorem formulář, pak formuláři. Pokud dojde ke stisknutí a podržení tlačítka myši nad prvkem button na formuláři, začnou se zprávy MouseMove zasílat buttonu i když kurzorem z tlačítka odjedete (při stále stisknutém tlačítku na myši).


Viz. http://www.uloz.to/10254994/mousemoveevent-exe

V HTML s JavaScriptem to funguje ale jinak. Zpráva chodí prvku pod kurzorem s vyjímkou, kdy pokud je kurzor nad tlačítkem tak díky probublávání dostane zprávu i body. Pokud dojde ke stisknutí tlačítka myši nad buttonem a následně se vyjede mimo button, pak se zprávy zase zasílají body a né prvku button.


Děkuji

[Ladis]

V normálních aplikacích jsem zvyklý, že se po stisknutí zasílá původnímu prvku. Můžeš tak udělat, že po vyjetí z tlačítka se zruší tlačítku promáčknutí, ale po najetí zpátky se zas promáčkne (jsou tak všechny tlačítka ve Windows apod.). Samozřejmě stejně tak původnímu prvku musíš poslat i uvolnění tlačítka.
_________________
Award-winning game developer

[Dlaha]

Já teď zkouším místo probublávání použít observera.
http://cs.wikipedia.org/wiki/Observer

Mám udělanej singleton, který obsluhuje události. A objekt, který chce přijímat nějaké události, se u tohodle singletonu zaregistruje a už mu události chodí, dokud se zase neodregistruje. A navíc si objekt může vybírat, jaké druhy událostí bude chtít přijímat.
_________________
Other Inside
Greenlitnuto!

[Solid.Sn]

Rád bych se ještě zeptal, jakými způsoby se animuje GUI? V JS se animování většinou řeší reakcemi na události s timery. V mém případě mě napadá to nějak zakomponovat do OnRender / Render události / metody, které se vyvolávají při renderování všech jednotlivých prvků uživatelského rozhraní, ale není mi moc jasné jak bych to vyřešil.

[Mem]

Teď si nejsem přesně jistý, o který mechanismus ti jde. Vyvolat překreslení, tj. nějaké zprávy Invalidate z oblastí? Anebo vůbec počítání a aktualizaci času u jednotlivých prvků, které se mají animovat? Tam bys mohl zaregistrovat každý animovatelný prvek u nějakého providera navěšeného na timer (nebo lépe hlavní loop), který by všem zaregistrovaným prvkům posílal zprávu update a delta čas (teď koukám, že Dlaha psal něco o Observeru, to je nejspíš stejný přístup). Ti by si to vevnitř zpracovali, spočítali, a pokud se má animace změnit, vyvolali by ten Invalidate, nebo se rovnou překreslili. Pokud nechceš tu registraci řešit, tak mít tu vypočtenou deltu public přístupnou a jen vyvolat nějaký refresh všechn prvků v kontejneru (případně rekurzivně)