Diskusia, posledné príspevky

Asi najčastejšie je táto výnimka spôsobená, keď nejaký Page alebo UserControl sleduje zmeny na objekte, lebo má nastavený data-binding, a tento objekt sa zmení na inom threade. A práve tento prípad rozoberá spomínaný blog.

Reakcie

# ... 24. 1. 2012 13:38:17 T

Neviem, preco sa robi okolo toho take halo :-) Podla mna je to o dodrzani jednoduchych zasad.
VM by mal byt updateovany zasadne z GUI Threadu.
Z hladiska testovatelnosti (ak niekomu ide primarne o nu) by mali byt async volania riesene "nad" VM a nie na jeho urovni.

# @T 24. 1. 2012 21:04:32 liero

1. Vo wpfku to funguje aj bez toho
2. V GUI threade staci preposielat iba notifikacie, kedze ta vyvola iba zavolanie gettera, cize tam nevadi, ak medzi nastavenim property a naslednim zavolanim gettera z bindingu sa hodnota zmenila.
3. s kolekciami CollectionChanged to nieje take jednoduche. Tu je to dost velky problem, preto to vo wpf 4.5 vyriesili tak, ze to za nas riesi framework. zatial neviem ako, ale testoval som to a funguje to skvele.
4. Problem je, ku COM Objektom mozes pristupovat vzdy iba z toho thraedu v ktorom si ich vytvoril a to skoro nikdy nieje UI Thread, a potom by sa ti mohlo stat, ze kvoli prepinaniu sa do UI threadu by musel ten druhy thread cakat, co by mohlo mat velky performace efekt. da s to sice vzdy nejako obist, ale komplikovane.

pri klasickych asynchronnych scenaroc to nieje problem, ale asynchronne nerovna sa multithreadovo. Pri masivnom multithreadingu by si sa lahko zamotal, deadlockol a podobne

# ... 25. 1. 2012 8:54:16 T

1. v tom istom zmysle ako vo win forms.
2. 3. tomu celkom nerozumiem, ale ak chces povedat, ze musis invokenut notifyPropChanged v GUI threade tak je to len potvrdenie mojho tvrdenia. Property samozrejme updatenut mozes aj z ineho threadu ale musis zabezpecit aby sa na jej zmenu reagovalo v GUI threade. Samozrejme, get/set na nejakom objekte mozes volat napriec threadmi a ak z povahy kodu mas zabezpecene, ze sa nepobiju dve vlakna nemusis riesit nic, inak musis synchronizovat a najjednoduchsi a najbezpecnjsi sposob je v nasom scenari delegovat updateovanie VM do GUI threadu.
4. Ach. Zalezi ci ide o STA alebo MDA COM. GUI COM veci su samozrejme STA.
Co si chcel povedat "a to skoro nikdy nieje UI Thread" netusim. Ani to co si presne predstavujes pod "prepinanim sa" do GUI threadu. Skus mi vlastne vysvetlit o com je cely tento bod, skus mi nacrtnut scenar/problem, ktory opisujes, kludne aj kodom.

"pri klasickych asynchronnych scenaroc to nieje problem, ale asynchronne nerovna sa multithreadovo. Pri masivnom multithreadingu by si sa lahko zamotal, deadlockol a podobne"

na toto som uz fakt nemam silu reagovat :-( Len ma utvrd v tom, ze nestudujes na FITke.

# @ 26. 1. 2012 12:03:17 liero

1. v WPF mozes preposlat notifikaciu aj v inom threade, ten binding je natolko sikovny, ze si to zosynchronizuje s dispatcherom sam. Cize tento tutorial sa nevztahuje na WPF. Silverlight si to sam spravit nevie.

3. S kolekciami nesmies manipulovat v jednom threade a preposielat len notifikacie do GUI threadu. Preco to tak je, to by bolo na dlhsie vysvetlenie ao funguje WPF, ale pave preto si WPF 4.5 uz vie poradit aj s notifikaciami CollectionChanged v inom threade

4. WPFko musi bezat ako STAThread aplikacia. Z toho vyplyva aj to, ze com ku objektom mozes pristupovat iba z jedneho threadu, vacsinou to nechces z GUI threadu, lebo nechces aby ti UI mrzlo. Aspon takto som to ja pochopil z tych mojich skusenosti s WPF a COM.

Cele to bolo o tom, ze zasada, ze VM ma by updatovany iba z GUI threadu nieje vobec taka jednoducha ako sa zda. Castokrat je jednoduchsie pouzit Approach 2 z toho linku, akurat ze ten nefunguje s ICollectionChagned.

# T 26. 1. 2012 16:38:16 ...

1. Je mozne ze Binding je sikovny, ale co potom robi? Tipujem, ze si zisti, ci je invokenuty z GUI threadu a ak nie, ide cez dispatcher. Mozem overit.
V kazdom pripade je to len barla, ktora pomaha hasit zly design.
3a) Kludne mi daj aj dlhe vysvetlenie, ja sa neurazim. (jediny problem tam moze byt v thread safety collectiony).
3b) Len si tipnem, ze ze to riesenie spociva v tom, ze kontroluje ci je obsluha udalosti v GUI threade a deleguje sa do GUI threadu.
3c) Ak by si ju updateoval v GUI threade nemas problem.
4. WPF app nie je COM, cize ani STA. (je STA like), vyuziva user32 msgs(pumpu) na cross thread volania a synchronizuje sa koly kompatibilite s niektorymi klucovymi COM componentami, ktore WPF vyuziva(napr. clipboard?) s user32 thread modelom. Ak si uvedomis toto, nehrozi Ti ziadna katastrofa.

Update VM v GUI threade je (moje?) odporucanie. Vacsina problemov, ktore spominas vypliva prave z nerespektovania tohoto pravidla.
Ak to robis inak a/alebo sa spoliehas sa na nejake fmwk zazraky zarabas si na problemy a hasis zly design resp. Ti v tom pomahaju magicky vo frameworku. Navyse pri tomto pristupe nemas problem ani so SL ani WPF z hladiska VM.