Click here to Skip to main content
Click here to Skip to main content

Another way to Invoke UI from a Worker Thread

, 3 Oct 2005
Rate this:
Please Sign up or sign in to vote.
This article demonstrates an alternative way of invoking UI event handlers from a worker thread.

Introduction

This article demonstrates an alternative way of invoking UI event handlers from a worker thread.

Events from worker threads - the "traditional" way

One of the benefits of the .NET platform is a much simpler way of performing lengthy tasks while keeping the user interface responsive. You can create an object, fill its properties and fields with proper data and make one of the object's methods a background thread. And just don't forget to retrieve the result of its work some time later.

When a background also known as worker thread needs to display some information in a UI you just define an event, subscribe a UI object for this event and fire it in the background thread. The only problem is that the UI should be managed from its own thread that contains the message loop. Microsoft offers us a simple workaround.

Suppose we have an event handler like the following one:

void OnEvent(object sender, EventArgs e)
{
    // Update the UI
}

It would work for any object derived from System.Windows.Forms.Control. To make it thread-safe, you should add a little bit of code:

void OnEvent(object sender, EventArgs e)
{
    if(InvokeRequired)
        Invoke(new EventHandler(OnEvent), 
                    new object[] {sender, e});
    else
    {
        // Update the UI
    }
}

The InvokeRequired property of the Control class returns true if the method of the UI element is called from a different thread. In this case we should use interthread marshalling using the Invoke method.

The "traditional" way of making multithreaded Windows Forms programs is good, but imagine you have a rather chatty worker object that has a lot of events. So for each event you should modify your event handlers. I usually forget to do this and then hunt for bugs. I also think this workaround code is ugly and should be hidden from the worker's client. We should move it to the workers' methods and I'll show you how to do that.

Events from worker threads, an easier way

Microsoft uses a distinct pattern for raising events. Each event with the name AAA is accompanied with a protected method OnAAA that raises the event and can be overridden by the descendant classes. There are many reasons to use this pattern in your programs and I'm going to give you another one. Checking whether we are calling the UI from a non-UI thread should be performed in such a method.

You would ask how? Easy. The Control class actually implements System.ComponwentModel.ISynchronizeInvoke interface. This interface declares the property InvokeRequired and methods Invoke, BeginInvoke and EndInvoke so, in theory there are more message loop aware classes. While firing events we need to check if each target object implements this interface. If it does, we need to check the InvokeRequired property and instead of calling the event delegate directly we need to use the Invoke method. It means that for the event subscriber (a Form-derived class in most cases) this event will always be synchronous and the author of the subscriber won't need to bother about interthread marshalling.

However, we should keep in mind that all events are multicast delegates. Because of this we must check all event subscriber objects separately. This is an easy part, because System.MulticastDelegate class has the GetInvocationList method that returns an array of single cast delegates that represent the combined multicast delegate.

Suppose we have an event declared as:

public event EventHandler Event;

We should declare the accompanying method like this:

protected virtual void OnEvent(EventArgs e)
{
    EventHandler handler = Event;
    if(null != handler)
    {
        foreach(EventHandler singleCast in handler.GetInvocationList())
        {
            ISynchronizeInvoke syncInvoke = 
                       singleCast.Target as ISynchronizeInvoke;
            try
            {
                if((null != syncInvoke) && (syncInvoke.InvokeRequired))
                    syncInvoke.Invoke(singleCast, 
                                  new object[] {this, e});
                else
                    singleCast(this, e);
            }
            catch
            {}
        }
    }
}

The first line of the method, the assignment statement, makes the method thread safe. I get a local copy of the event handler and make sure that even if somebody modifies the Event there won't be any trouble. Then we check if there is any subscriber for the event. If there are subscribers, I check if the event's delegate target object implements the ISynchronizeInvoke interface. If it does and the object is in the UI thread I perform interthread marshalling. In all other cases I just call the delegate directly. I also catch all exceptions that a subscriber can throw. It is not a very good idea to ignore them but so far I haven't found a good way to pass them to the OnAAA method caller.

Sample

In the sample you'll find a simple component named Copier that copies one stream to another in the background thread. You might need a class like that if you copy big files or download data from Internet. The Copier class has some properties related to work progress, three thread-safe events Started, Progress and Finished and three public methods Start, Stop and Join that check the state of the Copier and if it is valid delegates the work to the System.Threading.Thread method.

The sample also contains the ProgressForm class that provides a simple UI for the Copier component and the MainForm class that allows the user to specify the names of the source and target files. Note that the Copier does not close the data streams; this is the responsibility of the Copier's client. The same is true for the ProgressForm class.

There are two points of interest in this code. First is the implementation of the OnStarted, OnProgress and OnFinished methods, they follow the described pattern. Second is the ability to cancel the worker thread. Initially, I derived ProgressEventArgs class from CancelEventArgs, but the Control.Invoke call does not marshal its arguments back to the calling thread. I've added the Stop call to the Copier class that gracefully stops the worker thread.

I wrote the sample using SharpDevelop IDE with NAnt 0.85 as the build system. With NAnt you should call Debug, Release or Doc targets; the latter creates the InvokeUI.chm HTML Help file in the doc folder. You can also use the build.bat file to compile the sample. Sorry, I have no Visual Studio and those of you who do will have to re-create the project. Just create an empty Windows Forms project and add all *.cs files to it.

License

Files Copier.cs, ProfressEvent.cs and ProgressForm.cs are covered by BSD-like license, see comments at the beginning of each file. The rest of the code is in public domain. Use the sample at your own risk.

Links

  • Here you can learn about SharpDevelop and download your copy.
  • Here you can learn about NAnt and download your copy. Personally, I recommend this tool.
  • MSDN article: "Defining an Event" - describes the Event/OnEvent pattern and shows how to optimize the event implementation by using System.ComponentModel.EventHandlerList class.
  • Articles by Chris Sells: "Safe, Simple Multithreading in Windows Forms" - simple and clear explanation on how multithreaded UI works in Windows Forms.
  • A blog entry by Patrick Cauldwell that describes a problem with InvokeRequired property.

Revision history

  • 03/09/05
    • Initial post.
  • 04/09/05
    • Fixed a serious bug with background thread canceling; fixed a ProgressForm label issue; HtmlHelp compilation added to the build file.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Alexey A. Popov
Web Developer
Russian Federation Russian Federation
I'm a system administrator from Moscow, Russia. Programming is one of my hobbies. I presume I'm one of the first Russians who created a Web site dedicated to .Net known that time as NGWS. However, the Web page has been abandoned a long ago.

Comments and Discussions

 
GeneralGeneric version Pinmemberjsoldi22-Dec-10 9:59 
GeneralQuestion PinmemberSDI200330-Oct-07 16:12 
GeneralRe: Question --- Found a solution but there must be a better way PinmemberSDI200330-Oct-07 18:53 
AnswerRe: Question --- Found a solution but there must be a better way PinmemberAlexey A. Popov31-Oct-07 9:56 
GeneralRe: Question --- Found a solution but there must be a better way PinmemberSDI200331-Oct-07 12:08 
QuestionRe: Question --- Found a solution but there must be a better way PinmemberSDI20031-Nov-07 3:14 
AnswerRe: Question --- Found a solution but there must be a better way PinmemberAlexey A. Popov1-Nov-07 5:25 
GeneralRe: Question --- Found a solution but there must be a better way PinmemberSDI20031-Nov-07 13:40 
GeneralRe: Question --- Found a solution but there must be a better way PinmemberAlexey A. Popov1-Nov-07 22:53 
AnswerRe: Question --- Found a solution but there must be a better way PinmemberSDI20032-Nov-07 20:00 
GeneralRe: Question PinmemberPaul B.24-Jan-09 9:16 
GeneralGeneric revisitation PinmemberNikso26-Jul-07 3:55 
GeneralRe: Generic revisitation PinmemberAlexey A. Popov31-Oct-07 9:52 
GeneralRe: Generic revisitation PinmemberShannon McCoy28-Jul-09 0:16 
GeneralRe: Generic revisitation Pinmemberjsoldi22-Dec-10 10:00 
QuestionVB.NET Conversion? PinmemberNightOwl88824-Jun-07 14:14 
AnswerRe: VB.NET Conversion? PinmemberChris Kolkman25-Jun-07 3:26 
GeneralRe: VB.NET Conversion? PinmemberAlexey A. Popov25-Jun-07 6:22 
GeneralRe: VB.NET Conversion? PinmemberChris Kolkman25-Jun-07 6:31 
AnswerRe: VB.NET Conversion - The Solution [modified] PinmemberNightOwl88825-Jun-07 17:38 
GeneralRe: VB.NET Conversion - The Solution PinmemberAlexey A. Popov26-Jun-07 6:32 
AnswerRe: VB.NET Conversion - The Solution PinmemberNightOwl88826-Jun-07 14:24 
Well, I have to agree on your first point.   Catching an exception and then retrying the same call again is typically only a pattern you see when accessing remote resources, such as when trying to connect over a network.   Although that isn't what happens in every case here, you see the point.   Since event code (in this case, event code that updates a UI) is client-related, there will never be a reason for a retry pattern.
 
You could argue that we can be using this object remotely using remoting, but if you have ever read any books on remoting then you know that using events with serve-side objects is not a best practice anyway. Events from remoting objects are unreiable because they may need to go through firewalls.
 
However, I have to disagree on your second point.   While I have to admit setting a boolean and checking for an exception afterward is a throwback to the days of non-structured error handling, if you were to swap the eventFired=True line with the syncInvoke.Invoke line there would never be a condition where the exception handler is called and the eventFired variable is True.   This is because there is no code between the syncInvoke.Invoke call and the exception handler that could potentially cause an exception.
 
Well, back to the first point.   It really doesn't make much sense for the try-catch block or the boolean variables to exist in the first place.   So, once again I have altered the OnEvent method to eliminate this extra code.   It is listed below after the rest of my rant.
 
For a time I assumed that since the UI code was on a seperate thread that the exception would not make it back to the calling code.   But a quick test proved this to be an incorrect assumption.   This also made me verify that the ManagedThreadId was different in the calling code and event handler code (and it was).   So, somehow the framework must keep track of which thread invoked which and propogate the exception back to the calling thread.
 
The bottom line is - with this method, if your event handler doesn't handle its own exceptions it could cause other registered event handlers not to receive their events.   This is of course only a problem if you register more than one event handler to receive the event (which probably won't happen most of the time unless you are updating more than one form from the event).
 
Here is the modified example:
 
      Public Sub OnEvent(ByVal sender As Object, ByVal e As EventArgs, ByVal [event] As System.Delegate)
            Dim handler As System.Delegate = [event]
            If handler IsNot Nothing Then
                  For Each singleCast As System.Delegate In handler.GetInvocationList()
                        Dim syncInvoke As ISynchronizeInvoke = CType(singleCast.Target, ISynchronizeInvoke)
                        If syncInvoke IsNot Nothing AndAlso syncInvoke.InvokeRequired Then
                              syncInvoke.Invoke(singleCast, New Object() {sender, e})
                        Else
                              singleCast.DynamicInvoke(New Object() {sender, e})
                        End If
                  Next
            End If
      End Sub
 
But then, if you really insist on the "one bad apple not spoil the whole bunch" pattern, you could always use the first example.   Alternatively, you could add a boolean parameter and make it an option (or overload) to make the code throw the exception immediately or store them for later and stack them using the InnerException overload of the Exception object to throw all of the exceptions at once after all of the event subscribers have been attempted.
 
Either way, I don't see the point of making it more than a one-line operation to raise an event, as copying and pasting all of this code from one event to another is error-prone and could cause maintenence issues if you change your mind later about how to implement it.
 
NightOwl888
GeneralRe: VB.NET Conversion - The Solution PinmemberAlexey A. Popov27-Jun-07 6:29 
GeneralRe: VB.NET Conversion? [modified] PinmemberStackohm15-Aug-09 8:39 
GeneralWow... PinmemberChris Kolkman19-Apr-07 9:20 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 3 Oct 2005
Article Copyright 2005 by Alexey A. Popov
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid