Home > C#, WPF > UI Thread, Dispatchers, Background Workers & Async Network Programming

UI Thread, Dispatchers, Background Workers & Async Network Programming

Both Silverlight and WPF have the concept of a UI thread. Whenever you tie that thread up, you make your application unresponsive. In Silverlight, if you’re on a page with other plug-ins, you make all the plug-ins unresponsive. (It’s actually per-process, but most modern browsers separate processes by tabs)

Async Network Calls

In order to keep from tying up the UI thread, you have to perform long-running processes on another thread. Often, but not always, those processes are network calls. In Silverlight, all network calls are async with no provision to handle them any other way. This lets you off the hook threading-wise, but requires that you understand how to chain those calls, and how to deal with libraries that have IAsyncResult callbacks that return on different threads.
TestServiceClient client = new TestServiceClient();

client.DoSomethingSlowCompleted+= (s, ea) =>{

     // do something with the results here

Background Worker

For other processes, the BackgroundWorker is a great, simple, way to do some background work while reporting progress to the UI. It takes all the dispatching work away, so you can feel free to manipulate the UI from the ProgressChanged and RunWorkerCompleted events. Do not touch the UI from the DoWork event, as that is actually running on a separate thread.

private BackgroundWorker _worker = new BackgroundWorker();

private void RunLongProcess() {    

     _worker.WorkerReportsProgress = true;

     ProgressBar.Minimum = 0;

     ProgressBar.Maximum = 100;

    // runs in Background Thread
     _worker.DoWork += (s, e) =>
           for (int i = 0; i < 100; i++)
                 // simulate long-running work

 // runs in UI Thread

     _worker.ProgressChanged += (s, e) => {
            // this is on the UI thread, so you can update UI from here.
            ProgressBar.Value = e.ProgressPercentage;

   // runs in UI Thread

     _worker.RunWorkerCompleted += (s, e) => {
            // clean up after your stuff, yes, you can touch UI here.

Of course, knowing how to set up event handlers using lambda expressions is always helpful 🙂


Sometimes, you spin off a thread of your own, or you have to deal with some of the crufty stacks where the callbacks come back on a different thread from the one that created the call. In those cases, you need to use a dispatcher to make a call back to the UI thread.

If the code is on a page, you can call the dispatcher property and pass it a function to execute (yes, more lambda in this example).

private void UpdateUI(){Dispatcher.BeginInvoke(() =>{ProgressBar.Value = 50;});}

But, if the code is in some sort of non-UI class, it gets more complex. You can do it this way, using a dummy control (like we did in Silverlight 2):

TextBlock _dispatcherObject = new TextBlock();private void UpdateUINasty() // avoid this approach unless it’s all you’ve got{_dispatcherObject.Dispatcher.BeginInvoke(() =>{SomePage.ProgressBar.Value = 50; });}

This example assumes the object itself was created on the UI thread. The better way is to use the Deployment object:

private void UpdateUINotSoNasty(){Deployment.Current.Dispatcher.BeginInvoke(() =>{SomePage.ProgressBar.Value = 50;});}

That’s better. Definitely the recommended approach for recent versions of Silverlight, including Windows Phone 7.


What about when you need to run something on a timer? The normal timer classes require manual dispatching to do any UI updates. However, Silverlight and WPF both have the DispatcherTimerclass that handles all that for you.

private void StartTimer(){DispatcherTimer timer = new DispatcherTimer();timer.Tick += (s, e) =>{
// do some very quick work here update the UI

StatusText.Text = DateTime.Now.Second.ToString();

timer.Interval = TimeSpan.FromSeconds(1);

Of course, realize that what you’re doing here is interrupting the UI thread, not really running anything on a separate thread. It’s not suitable for anything long-running and cpu-intensive, but rather something where you need to execute on a regular interval. Clock UI updates are a perfect example.


In general, I discourage folks from spinning off real threads. Very few people understand how to efficiently work with threads, so even if you’re a threading genius, the person coming in after you probably isn’t. In most cases, the Background Worker will provide you with what you need.

Silverlight doesn’t yet have it, but the Parallel Tasking support built into .NET 4 can really help you out should you really need to do more than two things at once. Definitely check it out.


Threading in Silverlight and WPF is a little trickier than some other technologies, because you have to worry about the UI thread. My intention here was to both inform you that this trickiness exists, and then show some ways of dealing with it.

  1. June 3, 2015 at 1:45 PM

    Hi to all, it’s actually a nice for me to go to see this website, it consists of
    useful Information.


  1. No trackbacks yet.

Thanks for your comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: