|
Solving the WPF screen update problem
with async and await
DOWNLOADABLE EXAMPLES:
Simplest example without cancel button
With cancellation using flag
With cancellation by throwing exception
As many of us have found out the hard way, the Windows WPF user interface
does not update the screen every time you change something on the screen.
If you do a long computation, writing results in a TextBox as you go,
you won't see anything in the TextBox until the computation finishes.
When I was not as old and wise as I am now, I spent a lot of time trying
to make WPF update its screen the way WinForms does.
Actually, my solutions are far from useless; you may need them if you are
hastily porting a WinForms program to WPF and don't have time to do things right.
See examples here.
The right way to keep a WPF application responsive, traditionally, has been
to put the computation into a BackgroundWorker object,
run it in the background, and have it communicate with the screen using
ReportProgress.
But now we have several newer tools for the same job.
Setting up background tasks is easier than it used to be, and the
keywords async and await give us a non-blocking way to wait
for a task to finish, without having to tell the task to trigger an event
when it finishes.
In what follows, I'll show you how to put all of these together to run
a background computation in a separate thread, let it write to the screen
periodically, and keep the UI responsive.
First, though, I'll take you through a few handy features of modern C#.
Lambda notation. Adapted from lambda calculus in formal logic
and the LAMBDA special form in Lisp,
lambda notation is
a way to describe a method by just writing it, without giving it a name.
That is, it's a way to write one or more C# statements in a place
where the language is expecting a delegate (a reference to a method).
Here's what lambda notation looks like:
(parameters) => { statement; statement;statement; }
There is a simpler case, where there are no parameters and just one
statement, which is actually an expression, such as a method call. Then you can write:
() => expression
such as, for example, () => MyMethod(myArg) (no semicolon is needed after it).
Task factory. You remember BackgroundWorker, the traditional class for
creating background tasks. Nowadays there's a simpler way. You can create a task
and start it running by just doing this:
var task = Task.Factory.StartNew( () => MyMethod(myArg1) );
or even
var task = Task.Factory.StartNew(MyMethod);
if MyMethod does not take arguments. The task starts running in
the background, and task is a reference to it.
The async and await keywords.
These give you a new, non-blocking way to wait for a background task to finish.
If you were using BackgroundWorker, you'd be wanting to set up an event handler to
detect completion of the task. You can still do that, but with async and
await it isn't necessary.
Here's how they work: async is used in the declaration of a method, to
enable it to be called with await. But it can still be called the old way
too, and it isn't obligated to do anything special.
Methods that are declared async should return tasks, not values.
The proper declarations are:
async Task<T>, where T is some type, if the method returns type T;
async Task if the method returns void;
async void if the method is an event handler (only), because event handlers can't return anything.
You will soon see an example of the last one, or I wouldn't even have mentioned it.
Now for await. The await statement takes as its argument an async task,
and it asynchronously waits for the task to finish.
That is, it doesn't block the CPU while waiting.
Instead, it shoves the entire rest of its own method into a continuation — a postponed action —
and queues it to be triggered by competion of the awaited task.
Meanwhile, it lets the original thread get on with whatever else it wants to do.
A miracle! Or at least a lot of work saved.
Putting these two together, suppose CountUp is the name of a parameterless
method that performs a time-consuming computation.
We can launch it and run it in the background with these two statements:
var task = Task.Factory.StartNew(CountUp);
// You can do other work here and even launch other tasks
await task;
Or even this one statement:
await Task.Factory.StartNew(CountUp);
So here's how we start the action. This is a button click event handler,
and it has to be declared async so it can use await,
and async void (rather than the usual async Task) because it's
an event handler.
When the user clicks on the start button, the computation starts,
proceeds, and finishes.
Housekeeping is done to take care of the cursor and to disable the button
while the activity is taking place, so the user can't double-launch it.
private async void buttonStart_Click(object sender, RoutedEventArgs e)
{
buttonStart.IsEnabled = false;
this.Cursor = textBox1.Cursor = Cursors.Wait;
var task = Task.Factory.StartNew(CountUp);
await task;
this.Cursor = textBox1.Cursor = Cursors.Arrow;
buttonStart.IsEnabled = true;
}
Invoke and InvokeAsync.
We need one more tool in our kit.
Recall that we want the background process to be able to write on the screen,
or more precisely, to make changes to components that belong to the UI thread
rather than its own thread.
That means it needs to perform cross-thread calls. Instead of calling a method
directly, it needs to place that method in the queue of actions for the UI thread.
That can be done with BeginInvoke, just as in WinForms, but I find it handier
to use the two new methods Dispatcher.Invoke and Dispatcher.InvokeAsync,
which take delegates, and hence lambda expressions, as their only argument,
and run the delegate on the application's main thread (the UI thread).
(More precisely, the argument is an Action, converted automatically from a delegate.)
The difference between the two is that Dispatcher.Invoke calls another
thread's method and waits for it to finish, but Dispatcher.InvokeAsync doesn't wait.
Using the latter will keep from slowing down the computation thread, but you're taking
the risk that the UI thread might not be able to keep up.
So here is the complete CountUp() method. It writes numbers into a TextBox,
pausing between them to do about a second of number-crunching:
private void CountUp()
{
for (int i = 0; i < 10; i++)
{
// Cross-thread call to update things on the screen
Dispatcher.InvokeAsync( () => ReportResults(i.ToString()) );
// Simulate a slow computation
for (int j = 0; j < 120000000; j++) { }
}
}
ReportResults, in turn, appends its argument to a TextBox on the screen and
scrolls it to the end.
Making it cancellable.
What if we want to allow the user to cancel the computation in progress?
That involves a CancellationToken object.
Unlike a simple global boolean variable, a CancellationToken
is guaranteed
to be thread safe.
We have to declare a CancellationTokenSource that is in scope
everywhere it is used:
// Object that will keep track of cancellation requests.
CancellationTokenSource canceler;
When the user hits the Cancel button on the screen, we have to set the
token to request cancellation:
// Event handler for cancel button
private void buttonCancel_Click(object sender, RoutedEventArgs e)
{
if (canceler != null)
{
canceler.Cancel();
}
}
And we have to make the "start" button create the canceler
and enable the cancel button, so it has a little more housekeeping to do:
private async void buttonStart_Click(object sender, RoutedEventArgs e)
{
buttonStart.IsEnabled = false;
this.Cursor = textBox1.Cursor = Cursors.Wait;
canceler = new CancellationTokenSource(); // create the canceler
buttonCancel.IsEnabled = true;
var task = Task.Factory.StartNew(() => CountUp(canceler.Token));
await task;
buttonCancel.IsEnabled = false;
this.Cursor = textBox1.Cursor = Cursors.Arrow;
buttonStart.IsEnabled = true;
}
Notice the underlined code — we have to create the task in a slightly fancier way
in order to pass the cancellation token to it as an argument. Of course,
the computation task has to look at the token periodically and bail out if
cancellation is requested. This doesn't happen automatically (nor would you
want it to). So here is what CountUp now looks like:
private void CountUp(CancellationToken token)
{
for (int i = 0; i < 10; i++)
{
// Check the flag
if (token.IsCancellationRequested)
{
Dispatcher.InvokeAsync( () => ReportResults("Cancelled") );
return;
}
// Cross-thread call to update things on screen
Dispatcher.InvokeAsync( () => ReportResults(i.ToString()) );
// Simulate a slow computation
for (int j = 0; j < 120000000; j++) { }
}
}
That's all. Not quite as complicated as BackgroundWorker,
and considerably more elegant and versatile.
Permanent link to this entry
|
.jpg)
.jpg)