Click here to Skip to main content
15,867,568 members
Articles / Programming Languages / C#
Article

Proper Threading in Winforms .NET

Rate me:
Please Sign up or sign in to vote.
4.87/5 (36 votes)
23 May 20033 min read 198K   4K   130   31
Illustrates a simple example of using the Invoke capabilities of Winforms

Introduction

This is a small sample application that I built, to figure out how to "properly" do background threading in Winforms under .NET.

There is a well known rule that in the Win32 environment, a control is "owned" by the thread that created it; therefore, no other thread should (or can) safely update a control in any manner. All updates should be "posted" to the thread that owns the control. This posting actually takes place in the examples, by using the Windows Message loop - something that has existed back from Win 3.0 (perhaps earlier) days. This Message Loop still exists in .NET and forms the basis of a "Single Threaded Apartment" which VB 6 knows all too well.

All the stuff I had read was confusing, had all the methods for the work in one single class (WinForm) file. This made it difficult to see the "separation" of the form elements and where the work would be done -- and how to signal back to the caller in a separate class.

I think this is a littler easier to understand.

Walkthrough

The application's form is pretty simple:

Sample screenshot

There is a delegate declaration that identifies the callback that the worker class method will utilize, to signal to the form, what information the primary form's method needs to update, the status of the WorkerClass processing.

C#
delegate void ShowProgressDelegate ( int totalMessages, 
                    int messagesSoFar, bool statusDone );

Within the form, the click event fires the method below:

C#
private void button1_Click(object sender, System.EventArgs e)
{
    ShowProgressDelegate showProgress = new 
                                ShowProgressDelegate(ShowProgress);
    int imsgs = 100;
    if ( cbThreadPool.Checked )
    {
        object obj = new object[] { this, showProgress, imsgs };
        WorkerClass wc = new WorkerClass();
        bool rc = ThreadPool.QueueUserWorkItem( new WaitCallback 
                                            (wc.RunProcess), obj);
        EnableButton( ! rc );
   }
   else 
   {
        //another way.. using straight threads
        //WorkerClass wc = new WorkerClass( this, showProgress, imsgs);
        WorkerClass wc = new WorkerClass( this, 
                showProgress, new object[] { imsgs } );
        Thread t = new Thread( new ThreadStart(wc.RunProcess));
        //make them a daemon - prevent thread callback issues
        t.IsBackground = true; 
        t.Start();
        EnableButton ( false );
   } 
}

The path taken is based upon the status of the CheckBox. The path is either use ThreadPool or a ThreadStart object. With the ThreadStart object, the only way to get "state" into the WorkerClass is via the constructor. So, I've implemented WorkerClass with 2 constructors that take parameters. The first constructor is a strict 3 param constructor. The second takes the same first 2 params, but the 3rd is a parameter array, allowing more flexibility in future implementations. The sample application only uses the 3 param constructor when the check box is not enable.

Regardless, the first 2 params setup the callback target for WorkerClass.

The ShowProgress method takes a simple list of 3 params that are used to update the text box and progress bar...

C#
private void ShowProgress ( int totalMessages, int messagesSoFar, bool done )
{
    textBox1.Text = String.Format( messagesSoFar.ToString() );
    progressBar1.Value = messagesSoFar;
    if ( done ) EnableButton ( done );
}

The WorkerClass constructor that we'll look at here is the one that takes the param list on the end:

C#
public WorkerClass ( ContainerControl sender, 
                Delegate senderDelegate, params object[] list)
{
    m_sender = sender;
    m_senderDelegate = senderDelegate;
    m_totalMessages = (int) list.GetValue(0);
}

This just sets up internal members to designate the Form and Form's method to call when ShowProgress needs to be called.

Now, the actual work is done in LocalRunProcess using internal instance members. The public method RunProcess provide the entry point for the caller. The current thread is also forced IsBackground (make it a daemon) so if the parent thread exits, all child threads will be aborted too.

LocalRunProcess calls BeginInvoke (Invoke is the synchronous method) on the sender, passing the delegate instance that was passed in by form on WorkerClass construction. This method call initiates a background call to place a message on the message loop for the form.

C#
private void LocalRunProcess()
{
    int i = 0;
    for ( ; i < m_totalMessages; i++)
    {
        Thread.Sleep(50);
        m_sender.BeginInvoke( m_senderDelegate, 
                new object[] { m_totalMessages, i, false } );
    }
    m_sender.BeginInvoke( m_senderDelegate, 
                new object[] { m_totalMessages, i, true } );
}
C#
public void RunProcess()
{
    Thread.CurrentThread.IsBackground = true; //make them a daemon
    LocalRunProcess();
}

Recommended reads

A few good articles on Winforms, and Winforms over the web. You'll see the confusion in the 1st 2 articles.

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


Written By
Web Developer
United States United States
I have over 15 years of experience in the Application Development. Unfortunately, I still remember punch cards from College and VisiCalc on the Apple II.

My recent experience (about 6 years) covers the 2 main camps in distributed computing: J2EE based and COM[+] / .NET.

Lately, it's been deep .NET, C#, ASP.NET and the rest of the .NET Framework.

I've been working on Internet related technologies since 1993, initially writing Perl scripts under the original NCSA Http server.

Comments and Discussions

 
GeneralRe: Now I can see the light... Pin
Shawn Cicoria27-May-03 2:08
Shawn Cicoria27-May-03 2:08 
GeneralRe: Now I can see the light... Pin
Stefan Koell27-May-03 2:55
Stefan Koell27-May-03 2:55 
GeneralRe: Now I can see the light... Pin
Shawn Cicoria27-May-03 11:30
Shawn Cicoria27-May-03 11:30 
GeneralRe: Now I can see the light... Pin
Stefan Koell27-May-03 21:54
Stefan Koell27-May-03 21:54 
GeneralRe: Now I can see the light... Pin
Shawn Cicoria28-May-03 0:42
Shawn Cicoria28-May-03 0:42 
GeneralRe: Now I can see the light... Pin
Shawn Cicoria27-May-03 11:39
Shawn Cicoria27-May-03 11:39 
GeneralRe: Now I can see the light... Pin
Ming Liu18-Jul-03 23:59
Ming Liu18-Jul-03 23:59 
GeneralRe: Now I can see the light... Pin
Shawn Cicoria19-Jul-03 2:15
Shawn Cicoria19-Jul-03 2:15 
I don't get the Event pattern down in this example and it's not a direct change, but Event's allow greater decoupling of sender & receiver, along with multiple subscribers.

I probably will put out a different example using events, but I've been heads down on a project for the last several months. Need air soon...

Shawn Cicoria
shawn@cicoria.com
GeneralRe: Now I can see the light... Pin
Shawnr8-Jan-08 12:08
Shawnr8-Jan-08 12:08 

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

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