开发者

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

开发者 https://www.devze.com 2023-03-28 16:02 出处:网络
I\'m hoping this isn\'t too dumb a question: I just started using MVVM light (love it so far! ).In the \"before time开发者_JAVA百科\" (ie before the use of MVVML), I had to ui dispatch any code that w

I'm hoping this isn't too dumb a question: I just started using MVVM light (love it so far! ). In the "before time开发者_JAVA百科" (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

0

精彩评论

暂无评论...
验证码 换一张
取 消