Problém s přístupem k objektu

[uiii]

Čau, mám takový problém. Zkusím nějak popsat mojí situaci.

Mám tři třídy (ale mělo by to platit pro obecný počet tříd) co se týkají GUI:

[Quiark]

[uiii]

Nebo tak jeste trochu to upresnim. Spis bych potreboval vedet jak se resi to kdyz mám proste naky to GUI. Tam vyvolam nejako hodne vnorenou tridu, ktera obsahuje button a kdyz na nej kliknu tak to proste v tom API ma vyvolat nejakou fci. To teda kdyby fce pro to ovladani API byli ve tride MainWindow, tak to si musim do vsech vnorenych predavat ten ukazatel na ni? To to nejde resit nejak jinak? Jak se tohle resi?
_________________
Twitter

[rezna]

[Quiark]

Tak máš možnost použít globální proměnnou/singleton. S tím jsou ale spojeny jisté problémy, je tady k tomu přínosné vlákno.

Já osobně to ale řeším tak, že když mám v GUI tlačítko, které má spustit nějakou operaci, tak si instanci té pracující třídy vytvořím v tom GUI a pak ji spustím. Dále GUI frameworky obvykle fungují tak, že handlery událostí tlačítek a dalších prvků jsou metody v třídě okna/formuláře, takže tam není problém mít přístup k těm datem.
_________________
Mám strach

[Ladis]

Pred lety jsem neco takoveho resil, a tak nize prikladam svoje objektove reseni v C++. Jde o prirazeni nejake funkce nejakeho objektu k vybrane udalosti objektu tlacitka apod. Tj. kliknu na tlacitko a zavola se funkce uplne jineho objektu. Kod nize funguje v GCC i MSVC:

[tuft]

Da se taky pouzit koncept signal/slot, jako pouziva treba Qt. Princip je podobnej tomu co pise Ladis, jen obecnejsi. Doporucuju tuhle knihovnu http://sigslot.sourceforge.net/ .

[uiii]

no mozna jeste muzu dodat ze to delam v gtkmm (objektova verze GTK) a ta ma jako signal/sloty ale stejne nevim jak to resit. Jinak to pouziva knihovnu libsigc++, takze sem akorat koukal na ni.
_________________
Twitter

[uiii]

Jako nakonec sem se rozhod ze to udelam, tak ze dycky pro tu urcitou tridu udelam nakej vlastni signal, kterej vysle o tridu vejs, ta zas pro to bude mit pripavenej signal, kterej posle zase vys, az se to dostane do ty MainWindow, ktera to pak preda tomu API. Asi to neni nejlepsi reseni, ale nevim jak to udelat lip a tehle se mi zda spon takovy prehledny a ty tridy se nesnazej poustet nic v jinech tridach takze takovy dobre "uzavreny".
_________________
Twitter

[Ladis]

[uiii]

[uiii]

Jako dik za ten kod. Ale nechci to zas moc komplikovat, ten by se spis hodil nekam kde nejsou k dyspozici zadny nastroje pracujici se signalama, ale kdyz uz to gtkmm je ma tak to radsi udelam nejak pomoci nich.
_________________
Twitter

[Laethnes]

Mno, když jsem si tohle četl (problém i diskuzi), úplně mě běhal mráz po zádech: přesně (doslova a do písmene... snad :3) jsem řešil taky... přemýšlel jsem nad tím několik měsíců (moc času na programování jsem neměl, tak jsem to aspoň řešil v hlavě) a nakonec jsem vymyslel jeden model. Nevím, zda je to dobrý nápad, nevím, zda je to efektivní (proto bych kdyžtak požádal o kritiku), ale podařilo se mě tím vykrýt většinu problémů, co jsem potřeboval vyřešit:

Mám jednotný systém událostí. Existuje jedna globální instance třídy událostí (v podstatě singleton starající se o události programu) (já to označil jako g_event), který obsahuje CEventManager - třída manažer událostí. Existuje jedna ACEventFactory - abstraktní třída továrna na události, od které mohou dědit jednotlivé typy událostí (jde o to, že chci mít co nejméně kód závislý na jiném) a při jejich inicializaci se v tomto manažeru registrují a dostanou svoje základní base_event_id. (Momentálně mám události obecné (klávesy, myš, apod) a GUI (stisk tlačítka, posun pohledu v něčem, co jsem nazval Case (skříň) - jde o obalení objektu tak, aby se zobrazoval v určeném obdélníku a kolem něj byly posuvníky, apod.).
Při spuštění tedy registruji jednotlivé typy událostí (základní, GUI, ...). Při každém reloadu událostí je generován seznam událostí, který ukládá podle typů do polí (používám STL) - ukládám jej do CEventContainer (třída kontejner událostí).
Každý objekt, který má s událostmi nějak pracovat musí obsahovat následující funkci:
bool Events(CEventContainer& i_events);
Nějaká třída A tímto způsobem přijme události. Projde jejich seznam (buď celý, nebo jen ten base_type, na který reaguje) a podle toho se zachová (např. nějaký input vezme písmena a uloží je do textu, který pak zobrazí ve funkci Draw()) a většinou je taky smaže ze seznamu; např. událost MouseMove - pokud se myš nachází nad tímto objektem, smaže tuto událost, díky čemuž ji nemůže vzít objekt pode mnou (který je zakryt).
Pokud tato třída A obsahuje nějaké další objekty, pošle jim zbytek seznamu událostí. A teď přichází to hlavní: pokud funkce vrátí true, znamená to, že instance třídy změnila svůj stav takovým způsobem, kterého by si měly všimnout objekty, které ji volaly. Pokud třída A nějaké může přijmout, podívá se do seznamu událostí po událostech, které by od volané třídy měla zpracovat. Podle toho se třída může rozhodnout opět poslat true (což může taky i v případě vlastních reakcí) a "předat" (on se ten kontejner událostí zpět neposílá - kdo ho poslal ho má i po odeslání, ve změněném stavu) zbytek třídě, která ji volala.
Události, které zůstaly naprosto nezpracované (rozumněj žádný objekt je nesmaže) se pak mažou při příštím reloadu (nepotřebujeme, aby to pole neúměrně narůstalo např. na události MouseButtonUp, která se nemaže).

Praktický příklad: pracuju na jedné jednoduché adventuře. Rozhodl jsem se jednotlivé obrazovky rozdělit do samostatných tříd (obecně tomu říkám "pohledy", např. CMenuView, COptionsView, CMainGameView apod), které dědí od jedné základní (ACView - abstraktní třída pohled) a podle návrhového vzoru stav mám uložen pointer na aktivní pohled (a někde mám seznam všech). A teď: mám aktivní pohled menu. Třídě CMenuView pošlu události. Ta obsahuje třídu z GUI - menu, tak putují události do menu. Menu obsahuje seznam objektů - potenciálních cílů uživatele a všem postupně pošle události. Pokud nějaký řekne, že něco změnil, menu zkontroluje stav a případně jako aktuální nastaví jiný objekt (tohle momentálně dělám proto, že vstup myši si zpracovávají jednotlivé objekty, ale klávesy si zpracovává samotné menu); každý objekt si pamatuje svoje ID které bylo nastaveno při tvorbě menu. Když se nějakému objektu pošle (pomocí funkce) zpráva Focus (zaměření) či Choose (položka byla vybraná), položka přidá příslušnou událost do seznamu (spolu s tímto ID) a pošle true. Menu si ověří aktivitu a pošle true. CMenuView nic nedělá, tak jen pošle zpět to, co poslalo menu. A tak to doputuje až do hlavního cyklu. Zde se projde seznam GUI událostí a když se narazí na událost "VybranáPoložkaVMenu", podívá se na jeho ID - to je nastaveno stejně jako ID daného pohledu, takže jenom prohodí pointer na pohled. A tak se od příštího snímku bude zobrazovat nová stránka. (Akorát bych měl vytvořit novou událost ChangeViewEvent, protože se může měnit i jinak, než přes menu; např. v hlavní hře stiskem ESC.)

Pozn.: Ano, vím, že to menu mám momentálně komplikované. Uvědomil jsem si to až po jeho dodělání... Jde o to, že jsem vycházel z toho, že možná budu chtít vysouvací menu (vnořené) a tak je třeba, aby položka menu byla plnohodnotný objekt, kterému se posílají zprávy a které posílá zprávy. Akorát jsem si teď uvědomil, že nevím, jak udělat, aby to menu přečetlo kliknutí myši mimo objekt, aby se to vysunuté mohlo zrušit (jde o to, že tu událost může smazat už jiný objekt, kterému to bylo posláno dřív a do kterého se kliklo...).
Na druhou stranu tento systém toho hodně řeší: pokud se budou vytvářet nějaká okna, stačilo by naprogramovat nějaký jednoduchý manažer oken: bude obsahovat seznam objektů v pořadí, v jakém se zobrazují a v opačném, v jakém si berou vstup (to, co je vidět úplně na vrchu si bere vstup jako první, ale kreslí se jako poslední). Kliknu myší a události jdou do toho nejvrchnějšího. Pokud si tuto událost nevezme (není v souřadnicích okna), zůstane v seznamu událostí a ten putuje do dalších a dalších oken. Až narazí na okno, na které uživatel klikl a to tuto událost smaže a vrátí true; tím správce oken ví, že se tohle okno snaží získat vstup a tak jej nastaví jako první a ostatní poposune.
Stejně tak lze snadno implementovat chybovou zprávu, která vyžaduje, aby si ji uživatel přečetl a klikl na např. OK/STORNO apod; prostě vždy bude vracet true a vždy bude mazat všechny události, aby se nedostaly k ostatním. Na kliknutí mimo sebe může zareagovat zablikáním, příp. zvukem. Prostě to umožňuje udělat relativně jednoduché, ale komplexní GUI. Akorát tu mám strašně moc objektů, které dědí od nějaké AC (abstraktní třída) s HODNĚ virtuálními metodami (přinejmenším Get/Set X/Y, GetWidth/Height, Run, Draw, Events, Destroy, destruktor (který volá destroy :3, takže vlastně nemusí být :3)).

Doufám, že tahle slohovka někomu k něčemu bude