Last time, we brought ThreadSwitcher.ResumeForegroundAsync and ThreadSwitcher.ResumeBackgroundAsync to C# for UWP. Today, we’ll do the same for WPF and Windows Forms.
It’ll be easier the second and third times through because we already learned how to structure the implementation. It’s just the minor details that need to be tweaked.
using System;
using System.Runtime.CompilerServices;
using System.Threading; // For ThreadPool
using System.Windows.Forms; // For Windows Forms
using System.Windows.Threading; // For WPF
// For WPF
struct DispatcherThreadSwitcher : INotifyCompletion
{
internal DispatcherThreadSwitcher(Dispatcher dispatcher) =>
this.dispatcher = dispatcher;
public DispatcherThreadSwitcher GetAwaiter() => this;
public bool IsCompleted => dispatcher.CheckAccess();
public void GetResult() { }
public void OnCompleted(Action continuation) =>
dispatcher.BeginInvoke(continuation);
Dispatcher dispatcher;
}
// For Windows Forms
struct ControlThreadSwitcher : INotifyCompletion
{
internal ControlThreadSwitcher(Control control) =>
this.control = control;
public ControlThreadSwitcher GetAwaiter() => this;
public bool IsCompleted => !control.InvokeRequired;
public void GetResult() { }
public void OnCompleted(Action continuation) =>
control.BeginInvoke(continuation);
Control control;
}
// For both WPF and Windows Forms
struct ThreadPoolThreadSwitcher : INotifyCompletion
{
public ThreadPoolThreadSwitcher GetAwaiter() => this;
public bool IsCompleted =>
SynchronizationContext.Current == null;
public void GetResult() { }
public void OnCompleted(Action continuation) =>
ThreadPool.QueueUserWorkItem(_ => continuation());
}
class ThreadSwitcher
{
// For WPF
static public DispatcherThreadSwitcher ResumeForegroundAsync(
Dispatcher dispatcher) =>
new DispatcherThreadSwitcher(dispatcher);
// For Windows Forms
static public ControlThreadSwitcher ResumeForegroundAsync(
Control control) =>
new ControlThreadSwitcher(control);
// For both WPF and Windows Forms
static public ThreadPoolThreadSwitcher ResumeBackgroundAsync() =>
new ThreadPoolThreadSwitcher();
}
The principles for these helper classes are the same as for their UWP counterparts. They are merely adapting to a different control pattern.
WPF uses the System.Threading.Dispatcher class to control access to the UI thread. The way to check if you are on the dispatcher’s thread is to call CheckAccess() and see if it grants you access. If so, then you are already on the dispatcher thread. Otherwise, you are on the wrong thread, and the way to get to the dispatcher thread is to use the BeginInvoke method.
In Windows Forms, controls incorporate their own dispatcher. To determine if you’re on the control’s thread, you check the InvokeRequired property. If it tells you that you need to invoke, then you call BeginInvoke to get to the correct thread.
Both WPF and Windows Forms use the CLR thread pool. As before, we check the SynchronizationContext to determine whether we are on a background thread already. If not, then we use QueueUserWorkItem to get onto the thread pool.
So there we have it, C++/WinRT-style thread switching for three major C# user interface frameworks. If you feel inspired, you can do the same for Silverlight, Xamarin, or any other C# UI framework I may have forgotten.
It was well worth the wait, you solved my async level loading problem in Unity so elegantly that I only have to add those helper methods between critical parts 🙂 Thanks a million Raymond !!!
The original Async CTP (C#) had thread switching as a concept but then it was taken out. It wasn't complete though. WinRT lumbered along late in the game. I promise you cannot scale as a human programmer without this paradigm.
A few non-obvious key principles for WPF:
- ref-count UI threads before exiting them (using statements are best), and on desired exit run the DispatcherFrame to flush events and check the count at the lowest...
Thanks for your better edition of thread switching. I’ve added all document comments and post your code and this page link at the end of my article: https://blog.walterlv.com/post/bring-thread-switching-tasks-to-csharp-for-wpf.html
Something is screaming at me that there must be a neat way to get the appropriate SynchronizationContext injected into this setup and to use that instead of having three different implementations (and having to pass a relevant control every time when trying to "get back" to the UI). Haven't worked it out yet though.
I suppose we could capture it during the first call to ResumeBackgroundAsync but that still leaves a gap if that's not the...
The tricky part is defining "appropriate". (When you say you want to "go back to where you started", you first have to define when "start" happens.) At the "start", you can grab the and remember it as the "place to get back to". You can then use this code to to switch back to "where you were when you started". (Note that this is basically what the default infrastructure does. It defines...