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));
}
}
Please refer to my answer here: Thread safe, Silverlight
I highly recommend exactly what you are suggesting.
IMO you don't need to dispatch at all! Only operations on ObservableCollection need dispatching.
Reference answer: Accessing ViewModel properties from separate thread
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With