Beginners Guide To Threading In .NET Part 5 of n

• Download demo project - 656 Kb

Introduction

I'm afraid to say that I am just one of those people, that unless I am doing something, I am bored. So now that I finally feel I have learnt tha basics of WPF, it is time to turn my attention to other matters.

I have a long list of things that demand my attention such as (WCF/WF/CLR Via C# version 2 book), but I recently went for a new job (and got, but turned it down in the end) which required me to know a lot about threading. Whilst I consider myself to be pretty good with threading, I thought yeah I'm ok at threading, but I could always be better. So as a result of that I have decided to dedicate myself to writing a series of articles on threading in .NET.

This series will undoubtely owe much to an excellent Visual Basic .NET Threading Handbook that I bought that is nicely filling the MSDN gaps for me and now you.

I suspect this topic will range from simple to medium to advanced, and it will cover a lot of stuff that will be in MSDN, but I hope to give it my own spin also. So please forgive me if it does come across a bit MSDN like.

I dont know the exact schedule, but it may end up being something like

• Introduction into threading in .NET
• Lifecycle Of Threads/Threading Opportunities/Traps
• Synchronization
• Thread Pools (last article)
• Threading in UIs (Winforms / WPF / Silverlight) (This article)
• The Future Of Threading (Task Parallel Library)

I guess the best way is to just crack on. One note though before we start, I will be using C# and Visual Studio 2008.

What I'm going to attempt to cover in this article will be

• Why Thread UIs
• Threading In WinForms
• Threading In WPF
• Threading In Silverlight

This article will be all about how to thread different types of UIs

Why Thread UIs

I guess we have all seen some pretty cool UIs and some pretty bad ones in our lives. I know when I use a UI the first thing that makes me want to un-install something is the application being unresponsive. I have a rule if something is unresponsive, it gets removed, no questions. It’s out.

So what could these software developers that made me un-install something have done differently?

Well, with a little for thought and a little threading knowledge, this situation could have been avoided.

I hope that at least a few of you have read the other articles in this series. If so is should come as no surprise to you, when I say these issues of unresponsive UIs could probably have been avoided if background tasks were run in background threads, leaving the UI to be responsive to further user interactions.

It is be allowing background work to carry on, and updating the UI when appropriate (say when the work is done) that a responsive UI can be constructed.

This article aims to show you a few techniques to work with to create UIs that are able to deal with a single or n-many background tasks whilst maintaining a responsive UI. I will be covering techniques for Winforms and WPF mainly but will give you some pointers for working with Silverlight.

Threading In WinForms

In this section I am going to show you how to use threads within a WinForms environment. This will typically be done with the BackgroundWorker component that was made available within .NET 2.0. This is by far the easiest way of creating and managing background threads within a UI. Thought it should be mentioned that it does not offer as much flexability as creating and managing your own threads. But armed with the information that the other articles in this series you should be able to create and manage your own threads easy enough.

The reason that the BackgroundWorker is not quite as flexable as creating your own threads is that it is designed for a particular usage pattern. The BackgroundWorker provides the following:

• The ability to run some background work
• The ability to run some background work, based on an input parameter
• The ability to show progress
• The ability to report completion
• The ability to be cancelled

It is great if this fits your needs, but for more finer detail control, you should to spawn and manage your own threads. For this section of the article though, I will just be using the BackgroundWorker, as it's the most common way to create and manage background tasks in UIs these days. As I say the other articles in this series give you all the tools you need if you find your need to something more exotic.

But for now let's march on and look at some examples using the BackgroundWorker.

Firstly A Bad Example

Now in order to understand the rest of this article is important to see a non working example, so as part of the code that this article provides I have provided a BAD example WinForms app.

When you try and run this, you will see something like

Now lets look at the code that created this handled Exception, well its pretty simple (we will be looking at the inner working of the BackgroundWorker later)

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace Threading.UI.Winforms
{
    public partial class BackgroundWorkerBadExample : Form
    {
        public BackgroundWorkerBadExample()
        {
            InitializeComponent();
        }

        private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
        {

            try
            {
                for (int i = 0; i < (int)e.Argument; i++)
                {
                    txtResults.Text += string.Format(
                        "processing {0}\r\n", i.ToString());
                }
            }
            catch (InvalidOperationException oex)
            {
                MessageBox.Show(oex.Message);
            }

        }

        private void backgroundWorker1_RunWorkerCompleted(object sender, 
            RunWorkerCompletedEventArgs e)
        {
            MessageBox.Show("Completed background task");
        }

        private void btnGo_Click(object sender, EventArgs e)
        {
            backgroundWorker1.RunWorkerAsync(100);
        }
    }
}

The important part to note here is the backgroundWorker1_DoWork() method. Notice that we catch an InvalidOperationException. The reason for this, is that in .NET windows programming there is one cardinal rule, and that is all controls must be accessed using the thread that created them. In this example we are not doing anything to marshall our background threads work to be done on the UI thread, thus we get the InvalidOperationException.

Luckily we can fix this in a number of ways, which I will be describe below. But before I show you how to fix this, let me just talk about how to work with the BackgroundWorker, it's really very very easy.

The BackgroundWorker, can be wired up using a few parameter changes and a few events.

The following table outlines how to do various things with the BackgroundWorker

Task	What needs setting
Report Progress	WorkerReportProgress = True, and wire up the ProgressChangedEvent
Support Cancelling	WorkerSupportsCancellation = True
Running without Param	None
Running with Param	None

You will see more by examining the attached code.

Some Now Some Better Options

So what I want to show you now are some options to marshall the background work to the UI thread. I have included 3 options

OPTION 1 : Use BeginInvoke (works with all versions of .NET)

try
{
    for (int i = 0; i < (int)e.Argument; i++)
    {
        if (this.InvokeRequired)
        {
            this.Invoke(new EventHandler(delegate
            {
                txtResults.Text += string.Format(
                    "processing {0}\r\n", i.ToString());
            }));
        }
        else
            txtResults.Text += string.Format(
                "processing {0}\r\n", i.ToString());
    }
}
catch (InvalidOperationException oex)
{
    MessageBox.Show(oex.Message);
}

This is probably the oldest way to marshall to the UI thread, but its also the most explict and really shows whats going on, and I think aids readability.

OPTION 2 : Use SynchonizationContext (works with .NET 2.0 and above)

private SynchronizationContext context;
.....
.....
//set up the SynchronizationContext
context = SynchronizationContext.Current;
if (context == null)
{
    context = new SynchronizationContext();
}
.....            
.....            
try
{
    for (int i = 0; i < (int)e.Argument; i++)
    {
        context.Send(new SendOrPostCallback(delegate(object state)
        {
            txtResults.Text += string.Format(
                      "processing {0}\r\n", i.ToString());

        }), null);
    }
}
catch (InvalidOperationException oex)
{
    MessageBox.Show(oex.Message);
}

This version uses a .NET 2.0 available object called the SynchronizationContext which is an object that allows us to Marshall to the UI thread uing the Send() method. Internally the SynchronizationContext is really nothing more than a wrapper for some anonomous delegates. Want proof, fire up Reflector and have a look. There is also a great CP article here by Leslie Sanford, which talks in detail about the SynchronizationContext, should you wish to know more.

OPTION 3 : Use Lambdas (works with .NET 3.0 and above)

Now we could also go completely mad, and replace the use of the anonomous delegate with a lambda which would give us something like

private SynchronizationContext context;
.....
.....
//set up the SynchronizationContext
context = SynchronizationContext.Current;
if (context == null)
{
    context = new SynchronizationContext();
}
.....            
.....            
try
{
    for (int i = 0; i < (int)e.Argument; i++)
    {
        context.Send(new SendOrPostCallback((s) =>
            txtResults.Text += string.Format(
                          "processing {0}\r\n", i.ToString())
        ), null);
    }
}
catch (InvalidOperationException oex)
{
    MessageBox.Show(oex.Message);
}

I guess it really depends on how happy your are with lambdas. I think they are ok for small tasks, but believe me I have seen them used in overload, and its not pretty. The next article will be very lambda intensive, as Task Parallel Library (TPL) seems to use loads of lambdas.

When you run either of these options in the demo code, you will get a very simple form that shows something like

What About Reporting Progress

You may of course want to report progress completed when using the BackgroundWorker, luckily this is also a snap. This snippet of code shows the most important parts of setting up the BackgroundWorker to report progress

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Threading;

namespace Threading.UI.Winforms
{
    public partial class BackgroundWorkerReportingProgress : Form
    {
        private int factor = 0;
        private SynchronizationContext context;

        public BackgroundWorkerReportingProgress()
        {
            InitializeComponent();

            //set up the SynchronizationContext
            context = SynchronizationContext.Current;
            if (context == null)
            {
                context = new SynchronizationContext();
            }
        }

        private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
        {

            BackgroundWorker worker = sender as BackgroundWorker;
            try
            {
                for (int i = 0; i < (int)e.Argument; i++)
                {
                    if (worker.CancellationPending)
                    {
                        e.Cancel = true;
                        return;
                    }

                    context.Send(new SendOrPostCallback( (s) =>
                        txtResults.Text += string.Format(
                        "processing {0}\r\n", i.ToString())
                    ), null);

                    //report progress
                    Thread.Sleep(1000);
                    worker.ReportProgress((100 / factor) * i + 1);

                }
            }
            catch (InvalidOperationException oex)
            {
                MessageBox.Show(oex.Message);
            }
        }


        private void btnGo_Click(object sender, EventArgs e)
        {
            factor = 100;
            backgroundWorker1.RunWorkerAsync(factor);
        }

        private void backgroundWorker1_ProgressChanged(object sender, 
            ProgressChangedEventArgs e)
        {
            progressBar1.Value = e.ProgressPercentage;
        }

        private void backgroundWorker1_RunWorkerCompleted(object sender, 
            RunWorkerCompletedEventArgs e)
        {
            MessageBox.Show("Completed background task");
        }

        private void btnCancel_Click(object sender, EventArgs e)
        {
            backgroundWorker1.CancelAsync();
        }
    }
}

Its very simple, we just wire up the BackgroundWorker.ProgressChanged event handler (backgroundWorker1_ProgressChanged in this case) and set the progress within the BackgroundWorker.DoWork event handler.

And to cancel the operation, we can simply call the BackgroundWorker.CancelAsync() method.

I have attached a small demo project, which when run will look like the following:

Threading In WPF

WPF is new to .NET 3.0, and I don't know how many of you are using this (Me I love it). The thing to note is that it's still produces code that are .NET and although a WPF app may look different from a WinForms app, some of the underlying plumbing is the same. Threading is one area, where the underlying idea is the same as WinForms.

Recall "the one cardinal rule, and that is all controls must be accessed using the thread that created them". Well this is the same in WPF. The only difference is that we must use a WPF object known as the Dispatcher, which provides services for managing the queue of work items for a thread.

I have created a BackgroundWorker which is totally fine to use in WPF. I have seen some folk look for days for something in WPF only to realise that they can simply use some of the same ideas from WinForms.

Anyway here is an example in WPF using the BackgroundWorker. I will not be showing the XAML as its not imortant to the example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Shapes;
using System.ComponentModel;
using System.Windows.Threading;

namespace Threading.UI.WPF
{
    /// <summary>
    /// Interaction logic for BackGroundWorker.xaml
    /// </summary>
    public partial class BackGroundWorkerWindow : Window
    {
        private BackgroundWorker worker = new BackgroundWorker();


        public BackGroundWorkerWindow()
        {
            InitializeComponent();


            //Do some work with the Background Worker that 
            //needs to update the UI. 
            //In this example we are using the System.Action delegate.
            //Which encapsulates a a method that takes no params and 
            //returns no value.

            //Action is a new in .NET 3.5
            worker.DoWork += (s, e) =>
            {
                try
                {
                    for (int i = 0; i < (int)e.Argument; i++)
                    {
                        if (!txtResults.CheckAccess())
                        {
                            Dispatcher.Invoke(DispatcherPriority.Send,
                            (Action)delegate
                            {
                                txtResults.Text += string.Format(
                                    "processing {0}\r\n", i.ToString());
                            });
                        }
                        else
                            txtResults.Text += string.Format(
                                "processing {0}\r\n", i.ToString());
                    }
                }
                catch (InvalidOperationException oex)
                {
                    MessageBox.Show(oex.Message);
                }
            };


        }

        private void btnGo_Click(object sender, RoutedEventArgs e)
        {
            worker.RunWorkerAsync(100);
        }
    }
}

This is very simliar to the WinForms example I showed earlier, but this time we MUST use a WPFism, which is the Dispatcher. Lets look at that in a bit more detail, the important part is this section. The things of note here are the use of the CheckAccess() this can be thought of as the equivalent to the WinForms InvokeRequired. The other thing of note is the use of the cast to a System.Action, this encapsulates a parameterless/returnless method. Other than these subtle differences, these code snippets look the same in my humble opinion.

WPF

if (!txtResults.CheckAccess())
{
    Dispatcher.Invoke(DispatcherPriority.Send,
    (Action)delegate
    {
        txtResults.Text += string.Format(
            "processing {0}\r\n", i.ToString());
    });
}
else
    txtResults.Text += string.Format(
        "processing {0}\r\n", i.ToString());
        

If we now compare that with the 1st option I gave you when working with WinForms:

WinForms

if (this.InvokeRequired)
{
    this.Invoke(new EventHandler(delegate
    {
        txtResults.Text += string.Format(
            "processing {0}\r\n", i.ToString());
    }));
}
else
    txtResults.Text += string.Format(
        "processing {0}\r\n", i.ToString());
        

I also wanted to show you how to use a ThreadPool is WPF (this would be the similiar in WinForms, just lose the WPF specific stuff, like Dispatcher/CheckAccess().

ThreadPool Usage

Attached is a small example that uses a ThreadPool (which I discussed in detail in part4 of this series). I have included 2 options which are as follows:

OPTION 1 : Use Lambdas

This example uses lambdas.

try
{
    for (int i = 0; i < 10; i++)
    {
        //CheckAccess(), which is rather strangely marked [Browsable(false)]
        //checks to see if an invoke is required
        //and where i respresents the State passed to the 
        //WaitCallback        
        if (!txtResults.CheckAccess())
        {
            //use a lambda, which represents the WaitCallback
            //required by the ThreadPool.QueueUserWorkItem() method
            ThreadPool.QueueUserWorkItem(waitCB =>
            {
                int state = (int)waitCB;

                Dispatcher.BeginInvoke(DispatcherPriority.Normal,
                    ((Action)delegate
                    {
                        txtResults.Text += string.Format(
                            "processing {0}\r\n", state.ToString());
                    }));
            }, i);
        }
        else
            txtResults.Text += string.Format(
                "processing {0}\r\n", i.ToString());
    }
}
catch (InvalidOperationException oex)
{
    MessageBox.Show(oex.Message);
}

The important part here is the way that the state is obtained for the WaitCallback. the State parameter for a WaitCallback is usually an object and WaitCallbacks are normally done as shown below in option 2. By using lambdas we are able to shorten the process some what. Where the waitCB is the actual state object which is an Object so must be cast to the correct type.

OPTION 2: Use More Explicit Syntax

try
{
    for (int i = 0; i < 10; i++)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), i);
    }
}
catch (InvalidOperationException oex)
{
    MessageBox.Show(oex.Message);
}
....
....
....
// This is called by the ThreadPool when the queued QueueUserWorkItem
// is run. This is slightly longer syntax than dealing with the Lambda/
// System.Action combo. But it is perhaps more readable and easier to
// follow/debug
private void ThreadProc(Object stateInfo)
{
    //get the state object
    int state = (int)stateInfo;

    //CheckAccess(), which is rather strangely marked [Browsable(false)]
    //checks to see if an invoke is required
    if (!txtResults.CheckAccess())
    {
        Dispatcher.BeginInvoke(DispatcherPriority.Normal,
            ((Action)delegate
            {
                txtResults.Text += string.Format(
                    "processing {0}\r\n", state.ToString());
            }));
    }
    else
        txtResults.Text += string.Format(
            "processing {0}\r\n", state.ToString());
}

Although this syntax is longer than the lambda example, it obviously more explicit. I think its a judgement call, if you are happy working with lambdas, go for it.

Threading In Silverlight

This section assumes you have the Silverlight 2.0 BETA installed.

"Silverlight 2 brings support for threading to the browser. You can either directly start new threads using System.Threading.Thread and System.Threading.ThreadPool, or you can use the higher-level (and recommended) System.ComponentModel.BackgroundWorker type. The latter encapsulates the concept of executing work in the background (using a thread from the thread-pool) and updating the UI based on progress and/or completion of that work, which means that you can safely update the UI from the related events.

A lesser-known type that we introduced in beta 1 is System.Windows.Threading.Dispatcher. This type lets you execute work on the UI thread - something that's useful when you directly want to update the UI from a background thread. Since Silverlight always has a single UI-thread, there is only a single disatcher instance per Silverlight application. This instance is accessible via any DependencyObject or ScriptObject instances' Dispatcher property. Once you have a reference to a dispatcher, you can use its BeginInvoke method to dispatch your work. In Silverlight we added an overload which takes an Action, which means you don't need to add a cast or anything to help the compiler infer what type of delegate you want to pass:

Please note that you may not be able to find the dispatcher property via intellisense. It's marked as an advanced property, so you either need to update your VS settings to display advanced members, or you just need to ignore intellisense and assume your code will in fact compile regardless of what intellisense implies. The same goes for CheckAccess, which is actually marked as a member that should never be displayed. The main reason these members aren't always visible is because they shouldn't be as common as the other members on a DependencyObject. As I mentioned before, you'll probably want to use a BackgroundWorker most of the time instead.
Gotchas

There are a couple of things to be aware of. The first is that we try to guard against cross-thread invocations when this would potentially be unsafe. For example, we don't allow you to call into the HTML DOM or a JavaScript function from a background thread. The reason for this is that both assume to be invoked on the UI thread. Breaking this assumption can lead to unexpected behavior, including browser crashes.

The other thing to be aware of is creating deadlocks. Silverlight comes with primitives such as Monitor (encapsulated via the lock construct in C#) and ManualResetEvent which make it trivial to create a deadlock. A deadlock will cause most browsers to hang completely. While technically this isn't very different from some JavaScript that infinitely, it's often easier to accidentally create a deadlock than an infinite loop of code. For example, I've seen several people try to create a synchronous version of HttpWebRequest by letting the current thread wait for a ManualResetEvent to be notified by the response callback. HttpWebRequests however execute their callbacks on the UI thread, which means you have a deadlock right there. While ideally you avoid blocking the UI thread entirely, you should at least consider specifying timeouts when you use a synchronization object. For example, instead of the lock construct in C# (Monitor.Enter/Exit), consider using Monitor.TryEnter/Exit passing in a reasonable timeout, and instead of using ManualResetEvent's parameterless WaitOne, consider using one of the overloads."

http://www.wilcob.com/Wilco/Silverlight/threading-in-silverlight.aspx

What this all means is that we are able to do something like this to marshall threads to the UI thread in Silverlight. In this example I am creating a new thread and using a lambda to marshall to the correct UI thread. The 2nd option uses anonymous delegates, both are fine.

var myThread = new Thread(() =>
{
    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    // OPTION 1 : Use lambda
    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    txtResults.Dispatcher.BeginInvoke(() =>
        txtResults.Text = "Updated from a non-UI thread.");

    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    // OPTION 2 : Use anonymous delegate
    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    //txtResults.Dispatcher.BeginInvoke(delegate
    //{
    //    txtResults.Text = "Updated from a non-UI thread.";
    //});
});
myThread.Start(); 

We're Done

Well that's all I wanted to say this time. I hope you liked the article, and that it helps you produce more responsive UIs. Could I just ask, if you liked this article could you please vote for it. I thank you very much.

Possibly Next Time

If I have enough time/patience/energy, next time we will be looking at the future of threading, which is the Task Parallel Library (TPL), which is a BETA at the moment. It is very complicated but looks pretty interesting. We shall see if time is on my side.

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 25 of 27 (Total in Forum: 27) (Refresh) FirstPrevNext

WPF UI threading doubt santoshedwin 3:01 15 Oct '08   Hi Sacha Ur series of Articles on WPF are great and has helped me a lot in learning WPF My doubt is I have a main window from where i invoke a child Window (first window) by calling the show function of the window object.... after that i'm calling the ShowDialog function of another window. once the second dialog appears i'm not able to access the first window without closing the second window. My understanding is that the second window is a Modal dialog and the First one is a Modeless and the access to the modeless dialog should not be restricted when a modal dialog comes up.. Then y am i not able to access the first window? Am i missing some thing? Thanks in Advance T.Santosh Edwin modified on Wednesday, October 15, 2008 8:19 AM Sign In·View Thread·PermaLink Re: WPF UI threading doubt Sacha Barber 4:04 15 Oct '08   My understanding is showDialog() is as you say a call to show a modal form, so you will not get anything else happen until the modal form is closed. You can prove this by putting a break point on next line after the showDialog() call and watch it. Then use just the show on the new form and watch the difference Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Re: WPF UI threading doubt santoshedwin 20:31 15 Oct '08   sorry i should have been a little more explanatory My coding looks something like this public void ShowMe() { Window2 wnd =null; Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, (ThreadStart)delegate() { wnd = new Window2(); }); Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, (ThreadStart)delegate() { wnd.Show(); }); } private void FirstButton_Click(object sender, RoutedEventArgs e) { Thread Thrd = new Thread(new ThreadStart(ShowMe)); Thrd.Start(); } private void SecondButton_Click(object sender, RoutedEventArgs e) { Window3 wnd1 = new Window3(); wnd1.ShowDialog(); } I'm bringing up the Modeless dialog first in a thread and after that i bringup the Modal dialog. Once the modal dialog comes up i'm not able to access the Modeless dialog which is already open in a thread. T.Santosh Edwin Sign In·View Thread·PermaLink Re: WPF UI threading doubt Sacha Barber 23:28 15 Oct '08   Yeah this is what I would expect. Modal (ShowDialog()) means that the window that was shown modally has focus no matter what. Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Thanks woelig 10:49 25 Sep '08   Hope there’s another one of your article! Thanks for all your hard work! Sign In·View Thread·PermaLink How to use thread in a UserControl ? Wade Tang 17:35 16 Sep '08   First at all, these series of articles are great helpful for my job. Thank you !! My problem is that I want to start a thread which runs in a UserControl from Main Form(or Main thread). I use BeginInvoke and SynchonizationContext, but they don't work. Can you help me ? Thanks ! Sign In·View Thread·PermaLink Re: How to use thread in a UserControl ? Sacha Barber 2:15 18 Sep '08   So just expose a method/property on your usercontrol, and create a new thread in the method/property of the usercontrol. Then have the main form call that method. Check out my threading series, that should help you. Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Why do you check for the InvokeRequired? Shady Sayed 11:02 17 Aug '08   Hello Sacha, I really do not get why do you check for InvokeRequired in the following snippet if (this.InvokeRequired) { this.Invoke(new EventHandler(delegate { txtResults.Text += string.Format( "processing {0}\r\n", i.ToString()); })); } else txtResults.Text += string.Format( "processing {0}\r\n", i.ToString()); The way I understand it (didn't try it though) is that Control.Invoke method will work even when called from the thread that created the control, so why not just call it without the if-else? this.Invoke(new EventHandler(delegate { txtResults.Text += string.Format( "processing {0}\r\n", i.ToString()); })); Thanks, Shady Sign In·View Thread·PermaLink Re: Why do you check for the InvokeRequired? Sacha Barber 22:33 18 Aug '08   Its expensive operation, so if you dont need to do it, dont waste time marshalling thread (Invoke) Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink 5.00/5 (1 vote) Thanks... Norbert Freitag 4:38 15 Aug '08   ... for that article. Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: Thanks... Sacha Barber 22:32 18 Aug '08   No problem Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Passing Data to UI Cockeyed Bob 13:04 12 Aug '08   Another great article in your series! However, all the options that you discuss show how to access a UI control from the worker thread. I would like to keep the code in the worker thread independent from whatever UI it may be attached to, so that the worker thread can be reused in different situations, regardless of how the UI will be handling the information from the worker. Do you have any comments on the best way to pass data from the worker thread to th UI thread and letting the UI know when updated information is ready -- perhaps via the ProgressChangedEvent ? Keep up the good work! Sign In·View Thread·PermaLink Re: Passing Data to UI Sacha Barber 3:10 13 Aug '08   I would use an event within a class that had a manually created thread in it. In the class where the thread was created I would make UI accessible methods to control the thread class like Abort()/Start()/Pause()/Resume() etc etc, but I would also create an event in the custom thread class that the UI could subscribe to. The event could use some custom event args to communicate with the UI. But you will still have to marshall any update to the UI using the methods shown in this article, as the event and subscription delegate handler will be on the custom thread class not the UI. Hope that makes sense. Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Very interesting subject! Muammar© 21:08 11 Aug '08   I didn't read 'till the end yet but this's one of the most interesting subject I've read. I guess this article will be more and more popular very soon! Again, thank you for your generous and valuable contributions Sacha.. You are a bright gem in the CP! All generalizations are wrong, including this one! (\ /) (O.o) (><) Sign In·View Thread·PermaLink Re: Very interesting subject! Sacha Barber 22:52 11 Aug '08   I hope people find it useful Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Brilliant Article HuntrCkr 22:10 10 Aug '08   Hi Sacha I follow your exploration of WPF religiously, and find your articles excellent. This series is another example of just how well you can explain things, although I have not learned much since I use threading all the time. Still gets my 5 though One little problem though. In your table where you list the Tasks and What needs setting up, you have swapped the first two around. Cancellation requires setting up SupportsCancellation, etc. A minor problem, since it is obviously coded correctly in all the examples, but still a typo. Sign In·View Thread·PermaLink Re: Brilliant Article Sacha Barber 22:53 10 Aug '08   Cool Ill fix that now. If you think this is a good article and you use threading a lot, I have done my job well. So thats good to hear Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·