So say in an MVVM environment, I'm in a background thread and I'd like to run an update on a ui control. So normally I'd go myButton.Dispatcher.BeginInvoke(blabla) but I don't have access to myButton (because the viewmodel doesn't have access to the view's controls). So what is the normal pattern for doing this?
(I guess there's always binding, but I'd like to know how to do it via the dispatcher)
I usually use Application.Current.Dispatcher: since Application.Current is static, you don't need a reference to a control
From Caliburn Micro source code :
public static class Execute
{
private static Action<System.Action> executor = action => action();
/// <summary>
/// Initializes the framework using the current dispatcher.
/// </summary>
public static void InitializeWithDispatcher()
{
#if SILVERLIGHT
var dispatcher = Deployment.Current.Dispatcher;
#else
var dispatcher = Dispatcher.CurrentDispatcher;
#endif
executor = action =>{
if(dispatcher.CheckAccess())
action();
else dispatcher.BeginInvoke(action);
};
}
/// <summary>
/// Executes the action on the UI thread.
/// </summary>
/// <param name="action">The action to execute.</param>
public static void OnUIThread(this System.Action action)
{
executor(action);
}
}
Before using it you'll have to call Execute.InitializeWithDispatcher() from the UI thread then you can use it like this Execute.OnUIThread(()=>SomeMethod())
I tend to have my ViewModels inherit from DependencyObject and ensure that they are constructed on the UI thread, which poises them perfectly to handle this situation - they have a Dispatcher property that corresponds to the UI thread's dispatcher. Then, you don't need to pollute your view with the ViewModel's implementation details.
Some other pluses:
Application.Current.Dispatcher)
The ViewModelBase of Catel has a Dispatcher property that you can use.
You could raise an event on your View Model (perhaps using a naming convention to indicate it's going to be raised from a non-UI thread - e.g. NotifyProgressChangedAsync). Then your View whom is attached to the event can deal with the dispatcher appropriately.
Or, you could pass a delegate to a synchronizing function to your View Model (from your View).
Pass the UI thread's dispatcher to the ViewModel's constructor and store it in the VM.
Take note that each thread may have its own dispatcher. You are going to need the UI thread's!
Most of the time you don't need the Dispatcher in a ViewModel (> 99% of the time). Earlier versions of .NET didn't marshal PropertyChanged events to the UI thread appropriately, which caused issues. There was a way around it, which required you to raise that event in a way that was aware of the Dispatcher and could automatically marshal when needed. .NET 3.5 and above do this automatically now.
Because the Dispatcher is a UI concept, its presence in a ViewModel is a huge code smell. It suggests that you are doing something wrong. More likely, you either need to inject something which abstracts your ViewModel from the UI resource you are manipulating (changing the mouse cursor is a good example), or you've actually coupled the View to the ViewModel. In the latter case, you can usually fix this with some kind of attached behaviour which will subscribe to events and property changes on your ViewModel.
There is a hangup with this... CollectionChanged does have thread affinity (indirectly through CollectionViews which get automatically created by WPF), and the best way around this is to check for SynchronizationContexts on the event delegate subsribers when raising that event. It stinks, but it still doesn't require you to pass the Dispatcher to the VM.
