Update formulare z vlakna

[raul]

Zdar a silu,
mam aplikacku, ktera neustale komunikuje s externimi zarizenim (klido 10) v separatnich vlaknech. Na formulari jsou ruzne prvky pro ovladani tehto zarizenich a zarizeni posilaji docela casto jejich update. Stojim tedy pred otazkou, jestli radeji data prijmout a zavolat nejaky vetsi synchronize, ktery udela hafo podminek a aktualizuje jen zmenena data, ci to udelat tak, ze poslu zmenu dane komponenty - tzn synchronize by byly podstatne mensi, ale v o hodne vetsim mnozstvi. Co je tedy lepsi pristup ? (S gui nemam zase tak velke zkusenosti, vzdy jsem psal spise ty jaderne veci nize )

Dikes

[pf1957]

Zdar a silu,
mam aplikacku, ktera neustale komunikuje s externimi zarizenim (klido 10) v separatnich vlaknech. Na formulari jsou ruzne prvky pro ovladani tehto zarizenich a zarizeni posilaji docela casto jejich update. Stojim tedy pred otazkou, jestli radeji data prijmout a zavolat nejaky vetsi synchronize, ktery udela hafo podminek a aktualizuje jen zmenena data, ci to udelat tak, ze poslu zmenu dane komponenty - tzn synchronize by byly podstatne mensi, ale v o hodne vetsim mnozstvi. Co je tedy lepsi pristup ? (S gui nemam zase tak velke zkusenosti, vzdy jsem psal spise ty jaderne veci nize )

Zalezi na tom, jestli dokazes odhadnout "traffic". Jestli bude prilis velky, tak nema smysl updatovat UI pri kazde zmene, ale chce to updatovat nejaky ViewModel a jednou za cas (200 ms?) udelat refresh UI.  Coz je prace navic, takze jestli to funguje i v Lazarovi, tak pri mensim trafficu misto Synchronize pouzit Queue, kdy thread postne pozadavek a narozdil od Synchronize neceka a pokracuje v cinnosti.

[Ondřej Pokorný]

Na čisté ukázání výsledků z threadu je nejlepší Application.QueueAsyncCall. A se sběrem dat do nějaké větší skupiny bych si hlavu nelámal. Ta Queue se zpracovává při Idle, t.j. když má GUI zrovna čas, takže si to udělej tak, aby to bylo pro tebe co nejsrozumitelnější a nejpohodlnější.