delegate void UpdateProgressDelegate(int progress);

public void UpdateProgressBar(int progress)

{

if (this.InvokeRequired == false)

{

this.progressBarDownload.Value = progress;

}

else

{

this.Invoke(new UpdateProgressDelegate(UpdateProgressBar), new object[] { progress });

}

}

The new implementation is intended to replace this code and support the original ThreadBarrier concept.

Introducing the DelegateMarshaler

The DelegateMarshaler implementation is virtually identical to the ThreadBarrier except for four minor differences:

1. The marshaler is created using a static method DelegateMarshaler.Create() so an exception can be thrown if no SynchronizationContext exists (console app, or before UI is started, etc.)
2. If the calling thread is already the target thread (UI thread), then the delegate is invoked normally rather than a cross thread invoke. This is similar to InvokeRequired being false.
3. The DelegateMarshaler supports methods with 0 to 4 arguments.
4. Static methods wrap ThreadPool.QueueUserWorkItem in a type safe way.

A compact example

void buttonDownload_Click(object sender, EventArgs e)

{

DelegateMarshaler marshaler = DelegateMarshaler.Create();

DelegateMarshaler.QueueOnThreadPoolThread(

(fileName) =>

{

//simulate download

for (int i = 0; i < 100; ++i)

{

marshaler.Invoke(UpdateProgressBar, i);

Thread.Sleep(50);

}

marshaler.Invoke(ShowDownloadComplete, fileName);

},

“somefile.txt”);

}

private void UpdateProgressBar(int progress)

{

this.progressBarDownload.Value = progress;

}

private void ShowDownloadComplete(string fileName)

{

this.labelFileDownload.Text = fileName;

}

Using the DelegateMarshaler consists of creating the marshaler on the UI thread and invoking the methods that update the UI (preferably from the worker thread). Invoke will call the method synchronously, and BeginInvoke will call the method asynchronously allowing the worker to continue running while the UI updates. If your thread is a separate method altogether (which is usually the case), you would want to save the DelegateMarshaler instance as a private field in your form or control so it can be used in the thread method.

The DelegateMarshaler Implementation

public sealed class DelegateMarshaler

{

private SynchronizationContext _synchronizationContext;

public static DelegateMarshaler Create()

{

if (SynchronizationContext.Current == null)

{

throw new InvalidOperationException(“No SynchronizationContext exists for the current thread.”);

}

return new DelegateMarshaler(SynchronizationContext.Current);

}

private DelegateMarshaler(SynchronizationContext synchronizationContext)

{

this._synchronizationContext = synchronizationContext;

}

private bool IsMarshalRequired

{

get

{

return this._synchronizationContext != SynchronizationContext.Current;

}

}

public void Invoke<T>(Action<T> action, T arg)

{

if (this.IsMarshalRequired == false)

{

// already on the target thread, just invoke delegate directly

action(arg);

}

else

{

// marshal the delegate call to the target thread

this._synchronizationContext.Send(delegate { action(arg); }, null);

}

}

//simplifies use of threadpool so arguments do not need to be cast

public static void QueueOnThreadPoolThread<T>(Action<T> action, T arg)

{

ThreadPool.QueueUserWorkItem(delegate { action(arg); });

}

}

It is such a small class, feel free to modify it to fit your needs. Download the sample for the complete code and comments:

DelegateMarshalerSample

Notable Links
http://thevalerios.net/matt/2008/05/a-type-safe-backgroundworker-wrapper/
http://weblogs.asp.net/justin_rogers/articles/126345.aspx
http://www.codeproject.com/KB/cs/AOPInvokeRequired.aspx

Update – ThreadBarrier was a poorly chosen name, use the latest DelegateMarshaler implementation instead.

Previously I introduced the ThreadBarrier pattern which describes a simple technique for allowing worker threads to easily and safely communicate with controls on the UI thread. The key points from the previous article are:

A worker thread is completely contained within a class (and any objects the class references)

1. Events from this worker class are raised on the UI thread
2. A SynchronizationContext is used rather than Control.Invoke or Dispatcher.Invoke
3. The UI code does not have to worry about what thread is executing, it always assumes the UI thread (keeps code clean)
4. The ThreadBarrier needs to be created on a UI thread to capture the UI’s SynchronizationContext

Today’s article is a revisitation of the pattern to demonstrate several ways the technique can be used, as well as describe the flaw in the previous implementation. Yesterday’s article on events and threads provides an in depth background on the subtleties of events and multithreading. The contents of today’s post include:

• The New ThreadBarrier Code
• Sample UI and Worker Classes
• ThreadBarrier Technique #1: Subclassing an existing worker thread class
• ThreadBarrier Technique #2: Using extension methods on a SynchronizationContext
• ThreadBarrier Technique #3: Deriving from a ThreadBarrier
• ThreadBarrier Technique #4: Creating an instance of a ThreadBarrier
• ThreadBarrier Technique #5: Creating an adapter class to propagate events
• The Original ThreadBarrier Implementation Flaw
• ThreadBarrier FAQ

Download the examples.

The New ThreadBarrier Code

.NET 2.0

public class ThreadBarrier

{

private SynchronizationContext _synchronizationContext;

public ThreadBarrier()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

public void Post<T>(Action<T> raiseEventMethod, T e)

where T : EventArgs

{

if (this._synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem(delegate { raiseEventMethod(e); });

}

else

{

this._synchronizationContext.Post(delegate { raiseEventMethod(e); }, null);

}

}

}

.NET 3.5

public static class ThreadBarrierExtensions

{

public static void Post<T>(this SynchronizationContext synchronizationContext, Action<T> raiseEventMethod, T eventArgs)

where T : EventArgs

{

if (synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem((e) => raiseEventMethod((T)e), eventArgs);

}

else

{

synchronizationContext.Post((e) => raiseEventMethod((T)e), eventArgs);

}

}

}

The use of an anonymous delegate can be used for either implementation. The .NET 3.5 version uses a lambda expression just to demonstrate an alternate way of invoking the action.

Sample UI and Worker Classes

The sample UI and worker classes are very simple examples that will be the reference code for the techniques that follow. The UI code remains virtually unchanged throughout every technique which is ideal since it should not be concerned with threading:

These classes do not work together as is, they need a ThreadBarrier.

Sample Worker Class

public class WeatherChecker

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

public event EventHandler<WeatherEventArgs> HumidityChanged;

public event EventHandler<WeatherEventArgs> WindChanged;

public event EventHandler Stopped;

private bool _isStopRequested;

private Random _random;

public WeatherChecker()

{

this._isStopRequested = false;

//used for generating random weather information

this._random = new Random((int)DateTime.Now.Ticks);

}

public void Start()

{

Thread thread = new Thread(new ThreadStart(CheckWeather));

thread.IsBackground = true; //prevents thread from keeping app alive when app is closed

thread.Start();

}

private void CheckWeather()

{

while (this._isStopRequested == false)

{

OnTemperatureChanged(new WeatherEventArgs(Rand(30f)));

OnWindChanged(new WeatherEventArgs(Rand(15f)));

OnHumidityChanged(new WeatherEventArgs(Rand(100f)));

//Updates roughly 4 times per second

Thread.Sleep(250);

}

OnStopped(EventArgs.Empty);

}

public void RequestStop()

{

this._isStopRequested = true;

}

private float Rand(float max)

{

return (float)this._random.NextDouble() * max;

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

protected virtual void OnHumidityChanged(WeatherEventArgs e)

{

if (this.HumidityChanged != null)

{

this.HumidityChanged(this, e);

}

}

protected virtual void OnWindChanged(WeatherEventArgs e)

{

if (this.WindChanged != null)

{

this.WindChanged(this, e);

}

}

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

}

Sample UI Class

public partial class Form1 : Form

{

private WeatherChecker _weatherChecker;

public Form1()

{

InitializeComponent();

}

private void buttonStart_Click(object sender, EventArgs e)

{

this.buttonStart.Enabled = false;

this.buttonStop.Enabled = true;

this._weatherChecker = new WeatherChecker();

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

this._weatherChecker.HumidityChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_HumidityChanged);

this._weatherChecker.WindChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_WindChanged);

this._weatherChecker.Stopped += new EventHandler(_weatherChecker_Stopped);

this._weatherChecker.Start();

}

private void buttonStop_Click(object sender, EventArgs e)

{

this._weatherChecker.RequestStop();

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

this.labelTemperature.Text = String.Format(“{0:F1} C”, e.Value);

}

void _weatherChecker_HumidityChanged(object sender, WeatherEventArgs e)

{

this.labelHumidity.Text = String.Format(“{0:F0}%”, e.Value);

}

void _weatherChecker_WindChanged(object sender, WeatherEventArgs e)

{

this.labelWind.Text = String.Format(“{0:F0} mph”, e.Value);

}

void _weatherChecker_Stopped(object sender, EventArgs e)

{

this.buttonStop.Enabled = false;

this.buttonStart.Enabled = true;

this._weatherChecker = null;

}

}

ThreadBarrier Technique #1: Subclassing an existing worker thread class

The two classes above are doing nothing special to communicate with on another. An attempt to use the two together would fail since the worker class is raising events on the worker thread which is not allowed to access controls on the UI thread. Amazingly using a ThreadBarrier in the following way causes all events from the worker class to be automatically raised on the UI thread:

public class ThreadBarrierWeatherChecker : WeatherChecker

{

private ThreadBarrier _threadBarrier;

public ThreadBarrierWeatherChecker()

{

this._threadBarrier = new ThreadBarrier();

}

protected override void OnTemperatureChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnTemperatureChanged, e);

}

protected override void OnWindChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnWindChanged, e);

}

protected override void OnHumidityChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnHumidityChanged, e);

}

protected override void OnStopped(EventArgs e)

{

this._threadBarrier.Post(base.OnStopped, e);

}

}

That’s it! All it took was deriving from the worker class and posting the method that raises the events to the UI thread. The UI class should create an instance of ThreadBarrierWeatherChecker rather than WeatherChecker. This technique is handy if you do not own or can’t modify the code to the worker class.

ThreadBarrier Technique #2: Using extension methods on a SynchronizationContext

This technique requires the developer to not only have access to the WeatherChecker code, but also capture the UI’s SynchronizationContext in the WeatherChecker’s constructor:

private SynchronizationContext _synchronizationContext;

public WeatherChecker()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

…

}

Raising events now uses the _synchronizationContext field and the ThreadBarrier extension method:

this._synchronizationContext.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

this._synchronizationContext.Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

this._synchronizationContext.Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

ThreadBarrier Technique #3: Deriving from a ThreadBarrier

Again if the developer is in full control of the worker class, all that it takes is deriving from a ThreadBarrier to inherit the method that provides the posting to the UI thread:

public class WeatherChecker : ThreadBarrier

Raising the events is now a matter of calling the Post method in the base ThreadBarrier class:

Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

In order for the ThreadBarrier to work the WeatherChecker class needs to be created on the UI thread so the base ThreadBarrier class can capture the UI’s SynchronizationContext.

ThreadBarrier Technique #4: Creating an instance of a ThreadBarrier

If deriving from a ThreadBarrier is not an option, just creating an instance of a ThreadBarrier will work as well. This implementation is similar to the extension method sample, but the ThreadBarrier instance will hide the capturing and storing of the SynchronizationContext. This technique also requires the WeatherChecker to be created on the UI thread.

private ThreadBarrier _threadBarrier;

public WeatherChecker()

{

this._threadBarrier = new ThreadBarrier();

…

}

this._threadBarrier.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

this._threadBarrier.Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

this._threadBarrier.Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

ThreadBarrier Technique #5: Creating an adapter class to propagate events

This technique should be a last resort for the scenario where you can’t derive from the worker class and you are unable to modify its code. Since an extra set of events need to be created and subscribed, it can be dangerous and lead to memory leaks if the handlers are not properly removed.

Adapter Class (extra events removed for compactness)

public class ThreadBarrierWeatherChecker : ThreadBarrier

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

…

private WeatherChecker _weatherChecker;

public ThreadBarrierWeatherChecker()

{

}

public void Attach(WeatherChecker weatherChecker)

{

this._weatherChecker = weatherChecker;

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

…

}

public void Detach()

{

this._weatherChecker.TemperatureChanged -= new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

…

this._weatherChecker = null;

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

Post(OnTemperatureChanged, e);

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

}

The adapter class needs to provide a way to attach and detach to an already existing WeatherChecker instance. If the instance is not detached, it will result in a memory leak (the adapter class will be kept alive).

The Original ThreadBarrier Implementation Flaw

The first implementation of the ThreadBarrier used the event as a parameter:

protected void PostEvent<T>(EventHandler<T> eventHandler, object sender, T eventArgs)

where T : EventArgs

{

//do not raise the event if none was provided

if (eventHandler == null)

{

return;

}

this._synchronizationContext.Post(delegate { eventHandler(this, eventArgs); }, null);

}

The problem with this implementation is that the event handler delegate is copied when passed to the method. During execution of this method (which occurs on the worker thread) a UI thread could remove the original handler and dispose of the UI control. Since the method’s copy of the delegate will still get posted to the UI thread, the handler will be executed in the control’s code even though the control was already disposed. In other words, if the worker class is being used by multiple windows or controls that are opening and closing it could lead to this problem. See Problem #2 in the Events and Threads post.

ThreadBarrier FAQ

Q: Why not just use AsynchOperationManager.SynchronizationContext in the base class for each method post?
A: Since the methods are originally called on the worker thread, it means the call to the AsynchOperationManager.SynchronizationContext static property will be made from the worker thread. It will thus return an ‘empty’ SynchronizationContext. The call to the static property must be made on the UI and the SynchronizationContext must be ’saved’ so the worker can use it.

Q: Why not just use SynchronizationContext.Current?
A: The static SynchronizationContext.Current returns null when called from a worker thread, while AsynchOperationManager.SynchronizationContext will at least return an empty SynchronizationContext so we at least have some context reference.

Q: What is the difference between a ThreadBarrier and BackgroundWorker?
A: The BackgroundWorker must also be created on a UI thread. However, the BackgroundWorker does not provide an easy and transparent way (other than ReportProgress) to post events and data from the worker to the UI thread. A ThreadBarrier will support any kind of event since it uses generics.

Q: Why not use WPF’s built in cross-thread binding support?
A: A ThreadBarrier can be used in combination with WPF’s cross-thread binding. The difference is that a ThreadBarrier (and events) allow arbitrary code in the UI to execute. Properties just represent data.

Download the examples.

Update – ThreadBarrier was a poorly chosen name, use the latest DelegateMarshaler implementation instead.

With the advent of multi-core processors becoming standard in desktop PCs, it is clear we are on the verge of a shift in which high level software is designed and developed. First there was Object Oriented programming, then design patterns, and now there is multithreading. Multithreading has been around for decades in high end computing, but due to the now wide availability of multiple cores in a standard PC or laptop, it is only now that it is beginning to gain mainstream attention. There is a lot of work to do for tools, frameworks, and patterns to simplify the design and debugging of multithreading programs. While Microsoft has been working diligently to improve their tools (Visual Studio) and frameworks (Task Parallel Library) to bring multithreading into the mainstream, there is not yet enough guidance and information on the internet about proper threading techniques and design patterns.

This is where the ‘ThreadBarrier’ pattern comes in. Ultimately it is a way to help simplify the interaction between the UI and worker threads. A ThreadBarrier is an encapsulation of thread execution inside a class such that it is not exposed to the outside world. Rather, external events are first posted to the UI thread so any listener (on the UI thread) does not have to worry about threading issues. Like any pattern, there are times where it is ideal to use and there are times where it does not apply. Use at your own discretion.

Background

It seems that nearly every introductory threading example on the internet consists of a button click that starts a thread that performs some operation in a worker thread in the UI code behind. While simple examples are good, this immediately introduces a developer to starting threads In UI code and thinking that such techniques are normal.

The Problem

The problem is that the only way most developers know how to get data back to the UI thread is to use a UI control to post back the information. In case you are new to threading: the golden rule is that all UI controls (windows, textboxes, progressbars, etc.) can only be accessed from the thread that created them (the UI thread of course). This means a worker thread cannot do myTextBox.Text=”asdf” otherwise a cross-thread exception will be thrown. Controls provide a mechanism for executing a method on the UI thread (Control.Invoke, Control.BeginInvoke, Dispatcher.Invoke, Dispatcher.BeginInvoke).

WinForms example:

delegate void SetStartDelegate(bool enabled);

public void SetStartEnabled(bool enabled)

{

if (this.InvokeRequired == false)

{

this.buttonStart.Enabled = enabled;

}

else

{

this.Invoke(new SetStartDelegate(SetStartEnabled), new object[] { enabled });

}

}

WPF example:

delegate void SetStartDelegate(bool enabled);

public void SetStartEnabled(bool enabled)

{

if (this.Dispatcher.CheckAccess() == true)

{

this.buttonStart.IsEnabled = enabled;

}

else

{

this.Dispatcher.Invoke(DispatcherPriority.Send, new SetStartDelegate(SetStartEnabled), enabled);

}

}

There are tricks to make this a bit cleaner, but that is the common way to update the UI from any thread.

The combination of the Control’s UI thread rule and a Control’s ability to invoke on the UI thread essentially handcuffs developers into mixing threads with the UI and trying to make it work. Perhaps some have tried to be smart and hide the threads away deep in non-UI code to keep the UI clean. Those developers probably end up with the following questions (at least I did):

“How the heck do you get a control for invoking that deep in the execution and far away from the UI code? And more importantly, why does it have to be this way? There has to be a better way.”

The Answer

There is a better way, and it involves a SynchronizationContext. Rather than use a Control to post execution back to the UI, a SynchronizationContext provides this same capability without the UI Control requirement. Since a fantastic CodeProject article already covers the SynchronizationContext in depth, a summary will only be described here.

SynchronizationContext Overview

-SynchronizationContext is an abstract base class for:
-WindowsFormsSynchronizationContext
-DispatcherSynchronizationContext
-WinForms automatically creates an instance of WindowsFomsSynchronizationContext for a WinForms UI thread.
-WPF automatically creates an instance of DispatcherSynchronizationContext for a WPF UI thread.
-Static property AsyncOperationManager.SynchronizationContext gets the SynchronizationContext for the calling thread: WindowsFormsSynchronizationContext in WinForms and DispatcherSynchronizationContext in WPF.
-SynchronizationContext provides two methods (Send and Post) for synchronous or asynchronous method invocation.
-Getting AsyncOperationManager.SynchronizationContext on a non-UI thread (such as in a console app or worker thread) returns the base SynchronizationContext class that just invokes a method on the calling thread when Send is used, and calls a method on a ThreadPool thread when Post is used.

Introducing the ThreadBarrier ‘Pattern’

The ThreadBarrier pattern consists of a non-UI class encapsulating and executing a worker thread and always raising its events on the UI thread using a SynchronizationContext. The worker thread execution should never leave the class via events. Data and objects within the class may be operated upon by the worker thread but all external events must be called on the UI thread. If this technique is correctly followed then the listening UI code does not need to worry about thread checks and delegate posting.

Implementing a ThreadBarrier’ (.NET 2.0)

A ThreadBarrier can be implemented as an abstract class so that derived classes automatically inherit the necessary functionality to support the pattern.

public abstract class ThreadBarrier

{

private SynchronizationContext _synchronizationContext;

protected ThreadBarrier()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

The SyncronizationContext must be stored as a field so that it can be used by the worker thread in the derived class. Since the static AsyncOperationManager.SynchronizationContext property is called in the constructor, a critical requirement of properly using a ThreadBarrier derived class is that it must be created on the thread in which events want to be raised. In other words, create the class on the UI thread so that the UI’s context is captured. A worker thread can then use this context to post the methods that raise events back to the UI. The following protected method can be used for posting OnXXX methods:

public void Post<T>(Action<T> raiseEventMethod, T e)

where T : EventArgs

{

if (this._synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem(delegate { raiseEventMethod(e); });

}

else

{

this._synchronizationContext.Post(delegate { raiseEventMethod(e); }, null);

}

}

For an event such as:

public event EventHandler Stopped;

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

A ThreadBarrier derived class simply posts events to the UI in this way:

Post(OnStopped, EventArgs.Empty);

A small example of a class implementing a ThreadBarrier would look like:

public class WeatherChecker : ThreadBarrier

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

public event EventHandler<WeatherEventArgs> HumidityChanged;

public event EventHandler<WeatherEventArgs> WindChanged;

public event EventHandler Stopped;

private bool _isStopRequested;

private Random _random;

public WeatherChecker()

{

this._isStopRequested = false;

//used for generating random weather information

this._random = new Random((int)DateTime.Now.Ticks);

}

public void Start()

{

Thread thread = new Thread(new ThreadStart(CheckWeather));

thread.IsBackground = true; //prevents thread from keeping app alive when app is closed

thread.Start();

}

private void CheckWeather()

{

while (this._isStopRequested == false)

{

Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

//Updates roughly 4 times per second

Thread.Sleep(250);

}

Post(OnStopped, EventArgs.Empty);

}

public void RequestStop()

{

this._isStopRequested = true;

}

private float Rand(float max)

{

return (float)this._random.NextDouble() * max;

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

protected virtual void OnHumidityChanged(WeatherEventArgs e)

{

if (this.HumidityChanged != null)

{

this.HumidityChanged(this, e);

}

}

protected virtual void OnWindChanged(WeatherEventArgs e)

{

if (this.WindChanged != null)

{

this.WindChanged(this, e);

}

}

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

}

The key points are:
-WeatherChecker derives from ThreadBarrier
-The worker thread is started inside this non-UI WeatherChecker class.
-The WeatherChecker should be created on the UI thread.

Now the UI code is very clean and does not have to worry about threads:

public partial class Form1 : Form

{

private WeatherChecker _weatherChecker;

public Form1()

{

InitializeComponent();

}

private void buttonStart_Click(object sender, EventArgs e)

{

this.buttonStart.Enabled = false;

this.buttonStop.Enabled = true;

this._weatherChecker = new WeatherChecker();

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

this._weatherChecker.HumidityChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_HumidityChanged);

this._weatherChecker.WindChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_WindChanged);

this._weatherChecker.Stopped += new EventHandler(_weatherChecker_Stopped);

this._weatherChecker.Start();

}

private void buttonStop_Click(object sender, EventArgs e)

{

this._weatherChecker.RequestStop();

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

this.labelTemperature.Text = String.Format(“{0:F1} C”, e.Value);

}

void _weatherChecker_HumidityChanged(object sender, WeatherEventArgs e)

{

this.labelHumidity.Text = String.Format(“{0:F0}%”, e.Value);

}

void _weatherChecker_WindChanged(object sender, WeatherEventArgs e)

{

this.labelWind.Text = String.Format(“{0:F0} mph”, e.Value);

}

????????

void _weatherChecker_Stopped(object sender, EventArgs e)

{

this.buttonStop.Enabled = false;

this.buttonStart.Enabled = true;

this._weatherChecker = null;

}

}

Implementing a ThreadBarrier (.NET 3.5)

Since the requirement of deriving from a ThreadBarrier class is not ideal, in .NET 3.5 we can use extension methods to help us do the work.

public static class ThreadBarrierExtensions

{

public static void Post<T>(this SynchronizationContext synchronizationContext, Action<T> raiseEventMethod, T eventArgs)

where T : EventArgs

{

if (synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem((e) => raiseEventMethod((T)e), eventArgs);

}

else

{

synchronizationContext.Post((e) => raiseEventMethod((T)e), eventArgs);

}

}

}

Now the WeatherChecker class does not have to derive from a ThreadBarrier (but it now has to do the work in its constructor of saving a reference to the SynchronizationContext, the task previously left for the abstract ThreadBarrier class).:

public class WeatherChecker

{

private SynchronizationContext _synchronizationContext;

…

public WeatherChecker()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

…

}

Using an extension method on the SynchronizationContext allows us to post the OnXXX method:

this._synchronizationContext.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Using Lambda expressions also simplifies the handling of the events in the UI code:

this._weatherChecker.TemperatureChanged += (weatherChecker, weatherEventArgs) =>

{

this.labelTemperature.Content = String.Format(“{0:F1} C”, weatherEventArgs.Value);

};

Conclusion

The ThreadBarrier technique is an easy way to simplify the use of a worker thread and how it interacts with the UI. It is not the silver bullet for multithreading, but it does offer a way to think of a thread as an ‘object’ and hide the threading complexities. The UI and worker thread can be separated even further by designing a ThreadBarrier class to do nothing but handle events from other threading code (such as in a library that you do not have the code) and propagate just these events to the UI. This truly allows the business ‘logic’ to be free of any UI dependencies.

Samples

Download all Samples

UPDATE: The DelegateMarshaler has been revisited with a description of the 5 techniques in the sample.

The purpose of this post is to illustrate the various ways a feature or WPF application can be designed.

This post:
-Provides a peek into the vast world of WPF application designs.
-Provides sample code for each design
-Is for beginner/intermediate level WPF application developers.
-Is not a ‘best practices’ guide, it just provides a set of examples to help readers understand how classes and interaction between objects can be designed.
-Is not a ‘How-To.’ The examples are extremely contrived and few WPF features are demonstrated.

Before continuing I suggest reading the following articles:
-Dr. WPF’s A Project Needs Structure
-Introduction to Model/View/ViewModel
-100 Model/View/ViewModels of Mt. Fuji
-Model-View-ViewModel pattern example
-ViewModel example
-Advantages and disadvantages of M-V-VM
-UML diagram of M-V-VM pattern
-WPF Patterns
-Dan Crevier’s DataModel-View-ViewModel Series
-DataModel and VIewModel

I also recommend studying the source and design of the following applications:
-Family.Show
-SceReader

If all of these concepts are new to you, it can be a bit overwhelming. It is a lot of information and concepts to absorb. Hopefully the samples provided in this post can make it easier to understand how these concepts can come into play in a real-world application. Four designs will be demonstrated, starting from an extremely simple design all the way to one that uses DataModel-View-ViewModel. Each sample has the same features to make it easier to follow along the evolution of the design.

The features that are demonstrated are as follows:
-Two buttons allow a user to find currently loaded assemblies and types
-A textbox allows the search to be filtered.
-The results are displayed in a listbox

Download the samples: WPFDesigns
I recommend browsing the source and following along as each sample and design is explained.

Design #1

For such a simple application, it really does not take much to implement the solution using just a window with some buttons and a ListBox on it. When a button is clicked, a handler can call a method and update the listbox’s ItemsSource directly.

public void ShowTypes_Click(object sender, RoutedEventArgs e)
{
this.ResultsListBox.ItemsSource = FindTypeNames();
}

1. A button is clicked and handled in Window1’s code behind.
2. The loaded types are retrieved.
3. The ListBox’s ItemsSource is updated

Design #2

In this sample the buttons and textbox are moved onto their own user control, while the ListBox is moved to its own user control as well. Breaking up a UI into modular components allows the UI to remain simple as many features are added, and forces the logic handling to be more modular as well.

<UserControl x:Class=”WpfDesigns2.Controls.OperationsUserControl”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
DataContext=”{Binding RelativeSource={RelativeSource Self}}”>
<Grid>
<StackPanel>
<Button Click=”ShowAssemblies_Click”>Show Assemblies</Button>
<Button Click=”ShowTypes_Click”>Show Types</Button>
<TextBlock>Match:</TextBlock>
<TextBox Width=”80″ Text=”{Binding Path=MatchText}”/>
</StackPanel>
</Grid>
</UserControl>

Now that each user control is handling its own events there needs to be some way to get the results from one user control to the other. Since the Window1 is hosting both user controls, in this sample we will make it listen to an operation complete event that contains the results, and then send those results to the user control with the ListBox so it can be updated.

1. The button click is handled in the Operations user control.
2. Using the MatchText variable and a ReflectionHelper object that exists in the Operations user control, the assemblies or types are retrieved.
3. The user control raises an event letting listeners know the results are complete.
4. Window1 handles the event and sends the results to the ReflectionResults property of the user control with the ListBox.
5. Since the ListBox is bound to the ReflectionResults dependency property, the ListBox UI is updated automatically.

Design #3

This sample takes the design a step further and breaks the UI from the logic. You can think of the user controls as the View and the logic as the Model. A manager called ApplicationManager was designed to contain all of the objects in the model. This manager is created in Window1’s XAML:

<ObjectDataProvider x:Key=”ApplicationManager” ObjectType=”{x:Type local:ApplicationManager}” />

Since Window1 contains the manager in its resources collection, it can pass on the manager’s child models to each respective user control:

<controls:OperationsUserControl
Grid.Column=”0″
x:Name=”OperationsControl”
DataContext=”{Binding Source={StaticResource ApplicationManager}, Path=ReflectionHelper}”/>
<controls:ReflectionResultsUserControl
Grid.Column=”1″
x:Name=”ReflectionDisplayControl”
DataContext=”{Binding Source={StaticResource ApplicationManager}, Path=ReflectionResults}”/>

Now each user control’s DataContext is set to an object from the Model layer, so that the UI elements can bind to a single model element. When the user control needs to get its model object, it can do so in the following way:

private ReflectionHelper ReflectionHelper
{
get
{
return this.DataContext as ReflectionHelper;
}
}

A button click in the handler is as easy as:

public void ShowTypes_Click(object sender, RoutedEventArgs e)
{
this.ReflectionHelper.FindTypes();
}

In this sample the ApplicationManager is handling listening for the results from one model and passing the data on to the results model. This separates the logic from the views. Since the ReflectionResultsUserControl is bound to the Results property on the results model, it gets updated automatically when the ApplicationManager updates the results model. At this stage the UserControls are doing virtually nothing and the model layer is doing all of the work (which is ideal).

1. The button click is handled in the OperationsUserControl.
2. The FindTypes or FindAssemblies method is called on the user control’s model element.
3. The reflection helper model element does some reflection work
4. When the work is complete an event is raised
5. The ApplicationManager listening for the event updates the ReflectionResults model element.
6. Since the ReflectionResultsUserControl’s ListBox is bound to the Results property of the ReflectionResults model element, the ListBox is updated automatically.

Design #4

At this point we have probably taken the samples as far as they need to go. However, to demonstrate one way the DataModel-View-ViewModel pattern can be implemented, sample #4 takes the design to the next level. Since the other DataModel-View-ViewModel articles already do a great job explaining the concepts, I will just describe the design for sample #4. Let’s start with the diagram:

1. Using a RoutedCommand the OperationsView handles the button click command.
2. The view calls into its view model to perform an operation.
3. Since the OperationsViewModel was storing the MatchText data, it can call into its model (ReflectionHelper) to find types or assemblies.
4. The ReflectionHelper model retrieves the matching types or assemblies.
5. The ReflectionHelper raises its operations complete event
6. The ApplicationManager handles the event and updates the ReflectionResults model.
7. The ReflectionResults model raises a results changed event
8. The ReflectionResultsVewModel handles the event and puts the results data into a format suitable for its view.
9. Since the ListBox in the ReflectionResultsView is bound to the ObservableCollection in its respective view model, the ListBox is updated automatically.

For such a small application this design is overkill. However, as applications grow in size and complexity, the DataModel-View-ViewModel pattern keeps the overall design simple and minimizes dependencies. It also has the added benefit of making all of the various modules much easier to test, which is obviously crucial to the success of any large piece of software.

One interesting aspect of the DM-V-VM is how well the view can be abstracted from the rest of the application. For example, in this sample a new class call ApplicationViewState was created to hold the view models that represent the views. A DataTemplate allows us to represent the view model in any way we want:

<DataTemplate DataType=”{x:Type viewModels:OperationsViewModel}”>
<!–Sets the view model as the data context–>
<views:OperationsView DataContext=”{Binding}” />
</DataTemplate>

In the main window a ContentPresenter is used to represent a ‘place holder’ for its content which is specified to be one of the view models:

<ContentPresenter
Grid.Column=”0″
Content=”{Binding Source={StaticResource ApplicationManager}, Path=ViewState.LeftSideView}”/>
<ContentPresenter
Grid.Column=”1″
Content=”{Binding Source={StaticResource ApplicationManager}, Path=ViewState.RightSideView}”/>

By swapping the view models in the ApplicationViewState, the views automatically follow their respective view model. This is a crude demonstration of a data driven UI.

Disclaimer: Design #4’s sample is not a perfect implementation of the DM-V-VM pattern. I have seen it implemented in various different ways. It usually depends on the requirements of the particular application. As far as I can tell there is also no difference between what people call a DataModel and a Model. Since many WPF applications work with a data layer of some sort such as a database, they call it the DataModel. In this last sample I could have easily just called the ReflectionHelper and ReflectionResults Models (I think I did a few times anyways).

A Word of Warning: If you are new to WPF, attempting to implement DM-V-VM for your application is extremely difficult. There are many ‘gotchas’ along the way that put major roadblocks in the way of solving problems. Most of these are WPF specific. Your best source of help is the MSDN WPF Forum.

In the real world, applications are usually a mix of all four of these designs. No single design fits every application. It is up to you to learn from your mistakes in order to learn how to design and develop simple, flexible, scalable applications. No matter how experienced you get, there is always more to learn!

Download the samples: WPFDesigns

All questions, comments, and criticism are welcome!