Dispatching to the UI thread still required when using MVVM Light?

Question

I'm hoping this isn't too dumb a question: I just started using MVVM light (love it so far! ). In the "before time" (ie before the use of MVVML), I had to ui dispatch any code that would hit a property setter that had an INotifyPropertyChanged event raised in it.

I had (incorrectly? ) thought that requirement would disappear when using MVVMlight.

I still have to use it, correct? My experiments tell me a resounding yes.

So, heres the really stupid part - since there is a requirement to initialize the MVVML dispatcherhelper class somewhere, where I assume it saves the UI thread, why not have the RaisePropertyChanged call do the Dispatch automagically? It seems like a common thing to do?

Not a criticism per se, more of a "how come it doesn't work this way" :-)

Edit (copied from from a comment by author)

FWIW, I did this:

public class QViewModelBase : ViewModelBase { 
    protected override void RaisePropertyChanged(string propertyName) { 
        DispatcherHelper.CheckBeginInvokeOnUI( () => base.RaisePropertyChanged(propertyName)); 
    } 
    protected override void RaisePropertyChanged<T>(string propertyName, T oldValue, T newValue, bool broadcast) { 
        DispatcherHelper.CheckBeginInvokeOnUI( () => base.RaisePropertyChanged<T>(propertyName, oldValue, newValue, broadcast)); 
    } 
}

The question is good. However, I guess that Laurents rational lies in the design goal to support SL, WPF and WP7 in a single framework, plus allow the author of an application as much freedom as possible. Therefore, I think that Laurents approach is sensible! In addition, you always can modify your ViewModelBase in the way you did and ensure the behaviour in your project. — AxelEckenberger, Aug 18 '11 at 07:15
Oh yes, and I moved your code from the answer to [HiTech Magic](http://stackoverflow.com/users/201078/hitech-magic)'s answer to your OP to make your point clearer. — AxelEckenberger, Aug 18 '11 at 07:21
Just to be clear, I wasnt giving Laurent a hard time about not doing it (I am quite impressed with MVVMLight actually), it was more of a curiosity as to why you would ever *not* want to do this - even across WPF, SL & WP7. They all have the same issue with UI thread affinity when notifying of a property change I think? ps thank you for properly formatting my code- im new here, and had no idea how to get it to be readable :-) gotta read the FAQ I guess — Joe, Aug 19 '11 at 08:05
Never thought you did (giving Laurent a hard time that is). And yes reading the FAQ is a always good advice **;-)**. To make the code format properly just prefix 4 spaces, and add a new line at the start and bottom of your code. — AxelEckenberger, Aug 19 '11 at 10:54

score 1 · Answer 1 · edited May 23 '17 at 12:24

1

IMO you don't need to dispatch at all! Only operations on ObservableCollection need dispatching.

Reference answer: Accessing ViewModel properties from separate thread

edited May 23 '17 at 12:24

Community

1
1

answered Jun 05 '13 at 15:07

Pellared

1,242
2
14
29

score 1 · Accepted Answer · edited May 23 '17 at 12:31

1

Please refer to my answer here: Thread safe, Silverlight

I highly recommend exactly what you are suggesting.

edited May 23 '17 at 12:31

Community

1
1

answered Aug 17 '11 at 15:39

iCollect.it Ltd

92,391
25
181
202

Yes, I am of the same opinion- the MVVMLight toolkit should automatically wrap UI thread affinity code inside RaisePropertyChanged using DispatcherHelper. The reason for my original post was more like "Laurent is a smart guy, and it seems like it should work this way out of the box, so I must be missing why it doesnt". Im kind of hoping Laurent sees this and tells me why the framework wouldnt want to do this by default. – Joe Aug 17 '11 at 23:57
FWIW, I did this: public class QViewModelBase : ViewModelBase { protected override void RaisePropertyChanged(string propertyName) { DispatcherHelper.CheckBeginInvokeOnUI( () => base.RaisePropertyChanged(propertyName)); } protected override void RaisePropertyChanged(string propertyName, T oldValue, T newValue, bool broadcast) { DispatcherHelper.CheckBeginInvokeOnUI( () => base.RaisePropertyChanged(propertyName, oldValue, newValue, broadcast)); } } – Joe Aug 18 '11 at 04:07
Re: *Please refer to my answer here: Thread safe, Silverlight* this is what `DispatcherHelper.CheckBeginInvokeOnUI` does. – AxelEckenberger Aug 18 '11 at 07:19

Dispatching to the UI thread still required when using MVVM Light?

2 Answers2