Through a sample
application I will first demonstrate what a non-responsive UI is and how you get
one. Next I will demonstrate how to make the UI responsive through asynchronous
code. Finally I will demonstrate how to make the UI responsive through a much
simpler event-based asynchronous approach. I will also show how to keep the user
informed while the processing takes place with updates to Text Block's and a
Progress Bar.
What is a non responsive UI? Surely we've all witnessed a Windows Form or WPF
application that "locks up" from time to time. Have you ever thought of why this
happens? In a nutshell, it's typically because the application is running on a
single thread. Whether it's updating the UI or running some long process on the
back end such as a call to the database, everything must get into a single file
line and wait for the CPU to execute the command. So when we are making that
call to the database that takes a couple seconds to run the UI is left standing
in line waiting, unable to update itself and thus "locking up".
How can this unresponsive UI problem be resolved? Whether it's a Windows Form or
WPF application the UI updates on the main or primary thread. In order to keep
this thread free so the UI can remain responsive we need to create a new thread
to run any large tasks on the back-end. The classes used to accomplish this have
evolved over the different releases of the .NET Framework becoming easier and
richer in capabilities. This however can cause some confusion. If you do a
simple Google search on C# or VB and asynchronous or something similar you are
sure to get results showing many different ways of accomplishing asynchronous
processing. The answer to the question, which one do I use ?Of course depends on
what you're doing and what your goals are. Yes, I hate that answer also.
Since I cannot possibly cover every asynchronous scenario, what I would like to
focus on in this article is what I have found myself needing asynchronous
processing for a majority of the time. That would be keeping the UI of a WPF
application responsive while running a query on the database. Please note that
with some minor modifications the code in this article and in the downloadable
source code can be run for a Windows Form application also. In addition this
article is showing how to solve a specific problem with asynchronous
programming, by no means though is this the only problem asynchronous
programming is used for.
To help demonstrate synchronous, asynchronous and event-driven asynchronous
processing I will work through an application that transgresses through several
demos:
- Synchronous Demo (What not to do). Handle all
processing on a single thread and locking up the UI.
- Asynchronous Demo: Add a secondary thread to
free up that UI. I will also add some responsive text to the UI as a visual
indicator to let the user know where things are at.
- Asynchronous Event-Based Model Demo. With
this I will also add a progress bar and some responsive text.
What Not To Do
![locked-Up-UI-vb.net.jpg]()
Figure 1.
As I mentioned previously, what you do not want to do is run all you're
processing both back-end and UI on single thread. This will almost always lead
to a UI that locks up. Run the application, and click the Start button under
Synchronous Demo. As soon as you click the button try to drag the window around
your screen. You can't. If you try it several times the window may even turn
black, and you will get a "(Not Responding)" warning in the title bar. However,
after several seconds the window will unlock, the UI will update and you can
once again drag it around your screen freely.
Let's look at this code to see what's going on. If you look at the code for this
demo you will see the following:
First we have a delegate which is sort of like a function pointer but with more
functionality and provides type safety.
Delegate Function
SomeLongRunningMethodHandler(ByVal rowsToIterate As Integer) As String
We could easily not use the delegate in this sample and simply call the long
running method straight from the method handler. In fact, if I didn't already
know I was going to change its call to run asynchronously, I wouldn't use a
delegate. However, by using the delegate I can demonstrate how easy it is to go
from a synchronous call to an asynchronous call. In other words, let's say you
have a method that you may want to run asynchronously but you aren't sure. By
using a delegate you can make the call synchronously now, and later switch to an
asynchronous call with little effort.
I'm not going to go into too much more detail on delegates but the key to
remember is that the signature of the delegate must exactly match the signature
of the function (or Sub in VB) it will later reference. In this VB example the
delegate signature is for a Function that takes an Integer as a parameter and
returns a String.
Next we have the method handler for the click event of the button. After
resetting the Text Block to an empty String, the delegate is declared. Then the
delegate is instantiated (yes, a class is created when you create a delegate).
In this case a pointer to the function to be called by the delegate is passed as
a parameter to the constructor. What we now have is an instance of our delegate
(synchronousFunctionHandler) that points to the Function
SomeLongRunningSynchronousMethod. If you move down one more line you can see how
this method is called synchronously by the delegate. The delegate instance we
have is actually an instance of a class with several methods. One of those
methods is called Invoke. This is how we synchronously call the method attached
to the delegate. You may have also noticed the methods Begin Invoke and End
Invoke if you used intellisense.
Remember when I said that by using delegates we can easily move from synchronous
to asynchronous? You know have a clue as to how, and we will get into the
details of that soon.
Going back to our asynchronous example you can see the Invoke method is called
on the delegate instance. It is passed and integer as a parameter and returns a
string. That string is then assigned to a TextBlock to let the user know the
operation is complete.
Private Sub SynchronousStart_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs)Handles synchronousStart.Click
Me.synchronousCount.Text
= ""
Dim synchronousFunctionHandler As SomeLongRunningMethodHandler
synchronousFunctionHandler = New SomeLongRunningMethodHandler(AddressOfMe.SomeLongRunningSynchronousMethod)
Dim returnValue As String =
synchronousFunctionHandler.Invoke(1000000000)
Me.synchronousCount.Text
= "Processing
completed. " & returnValue & "
rows processed."
End Sub
This is the function
that the delegate calls. As mentioned earlier it could have also been called
directly without any use of a delegate. It simply takes an integer and iterates
that many times returning the count as a string when completed. This method is
used to mimic any long running process you may have.
Private Function SomeLongRunningSynchronousMethod(ByVal rowsToIterate As Integer) As String
Dim cnt As Double =
0
For i As Long =
0 To rowsToIterate
cnt = cnt + 1
Next
Return cnt.ToString()
End Function
The bad news is that implementing this demo asynchronously causes an
unresponsive UI. The good news is that by using a delegate we have set ourselves
up to easily move to an asynchronous approach and a responsive UI.
A More Responsive Approach
Now run the downloaded demo again, but this time click the second Run button
(Synchronous Demo). Then try to drag the window around your screen. Notice
anything different? You can now click the button which calls the long running
method and drag the window around at the same time without anything locking up.
This is possible because the long running method is run on a secondary thread
freeing up the primary thread to handle all the UI requests.
![asynchronous-Demo-in-vb.net.jpg]()
This demo uses the same SomeLongRunningSynchronousMethod as the previous
example. It will also begin by declaring and then instantiating a delegate that
will eventually reference the long running method. In addition, you will see a
second delegate created with the name UpdateUIHandler which we will discuss
later. Here are the delegates and event handler for the button click of the
second demo.
Delegate Function AsyncMethodHandler(ByVal rowsToIterate As Integer) As String
Delegate Sub UpdateUIHandler(ByVal rowsupdated As String)
Private Sub AsynchronousStart_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs)
Me.asynchronousCount.Text
= ""
Me.visualIndicator.Text
= "Processing,
Please Wait...."
Me.visualIndicator.Visibility
= Windows.Visibility.Visible
Dim caller As AsyncMethodHandler
caller = New AsyncMethodHandler(AddressOf Me.SomeLongRunningSynchronousMethod)
caller.Begin(Invoke(1000000000, AddressOf CallbackMethod, Nothing))
End Sub
Notice the event method starts
out similar to the previous example. We setup some UI controls, then we declare
and instantiate the first delegate. After that, things get a little different.
Notice the call from the delegate instance "caller" to Begin Invoke. Begin
Invoke is an asynchronous call and replaces the call to Invoke seen in the
previous example. When calling invoke we passed the parameter that both the
delegate and delegate method had in their signature. We do the same with Begin
Invoke; however there are two additional parameters passed which are not seen in
the delegate or delegate method signature. The two additional parameters are
Delegate Callback of type AsyncCallback and DelegateAsyncState of type Object.
Again you do not add these two additional parameters to your delegate
declaration or the method the delegate instance points to, however you must
address them both in the Begin Invoke call.
Essentially there are multiple ways to handle asynchronous execution using Begin
Invoke. The values passed for these parameters depend on which technique is
used. Some of these techniques include:
- Call Begin Invoke, do some processing, call
End Invoke.
- Using a Wait Handle of type IAsyncResult
returned by Begin Invoke.
- Polling using the Is Completed property of
the IAsyncResult returned by Begin Invoke.
- Executing a callback method when the
asynchronous call completes.
We will use the last
technique, executing a callback method when the asynchronous call completes. We
can use this method because the primary thread which initiates the asynchronous
call does not need to process the results of that call. Essentially what this
enables us to do is call Begin Invoke to fire off the long running method on a
new thread. Begin Invoke returns immediately to the caller, the primary thread
in our case so UI processing can continue without locking up. Once the long
running method has completed, the callback method will be called and passed the
results of the long running method as type IAsyncResult. We could end everything
here, however in our demo we want to take the results passed into the callback
method and update the UI with them.
You can see our call to Begin Invoke passes an integer which is required by the
delegate and delegate method as the first parameter. The second parameter is a
pointer to the callback method. The final value passed is "Nothing" because we
do not need to use the DelegateAsyncState in our approach. Also notice we are
setting the text and visibility property of the visual Indicator Text Block
here. We can access this control because this method is called on the primary
thread which is also where these controls were created.
Protected Sub CallbackMethod(ByVal ar As IAsyncResult)
Try
Dim result As AsyncResult
= CType(ar,
AsyncResult)
Dim caller As AsyncMethodHandler
= CType(result.AsyncDelegate,
AsyncMethodHandler)
Dim returnValue As String =
caller.EndInvoke(ar)
UpdateUI(returnValue)
Catch ex As Exception
Dim exMessage As String
exMessage = "Error:
" & ex.Message
UpdateUI(exMessage)
End Try
End Sub
In the callback method
the first thing we need to do is get a reference to the calling delegate (the
one that called Begin Invoke) so that we can call End Inoke on it and get the
results of the long running method. End Invoke will always block further
processing until Begin Invoke completes. However, we don't need to worry about
that because we are in the callback method which only fires when Begin Invoke
has already completed.
Once End Invoke is called we have the result of the long running method. It
would be nice if we could then update the UI with this result, however we
cannot. Why? The callback method is still running on the secondary thread. Since
the UI objects were created on the primary thread, they cannot be accessed on
any thread other than the one which created them. Don't worry though; we have a
plan which will allow us to still accomplish updating the UI with data from the
asynchronous call.
After End Invoke is called the Sub Update UI is called and is passed the return
value from End Invoke. Also notice this method is wrapped in a try catch block.
It is considered good coding standards to always call End Invoke and to wrap
that call in a try catch if you wish to handle the exception. This is the only
positive way to know that the asynchronous call made by Begin Invoke completed
without any exceptions.
Sub UpdateUI(ByVal rowsUpdated As String)
Dim uiHandler As New UpdateUIHandler(AddressOf UpdateUIIndicators)
Dim results As String =
rowsUpdated
Me.Dispatcher.Invoke(Windows.Threading.DispatcherPriority.Normal,
uiHandler, results)
End Sub
Sub UpdateUIIndicators(ByVal rowsupdated As String)
Me.visualIndicator.Text
= "Processing
Completed."
Me.asynchronousCount.Text
= rowsupdated & "
rows processed."
End Sub
Next we
can see the Update UI method. It takes as a parameter the return value from End
Invoke in the callback method. The first thing it does is to declare and
instantiate a delegate. This delegate is a Sub and takes a single parameter of
type string. Of course this means that the function pointer it takes in its
constructor must also point to a Sub with the exact same signature. For our demo
that would be the UpdateUIIndicators Sub. After setting up the delegate we place
the Update UI parameter into string. This will be eventually be passed into
Begin Invoke.
Next you will see the call to Invoke. We could have also used a call to Begin
Invoke here but since this method is only updating two UI properties it should
run quickly and with out the need for further asynchronous processing. Notice
the call to Invoke is run off Me. Dispatcher. The Dispatcher in WPF is the
thread manager for your application. In order for the the background thread
called by Invoke to update the UI controls on the primary thread, the background
thread must delegate the work to the dispatcher which is associated to the UI
thread. This can be done by calling the asynchronous method Begin Invoke or the
synchronous method Invoke as we have done off the dispatcher.
Finally Sub UpdateUIIndicators takes the results passed into it and updates a
Text Block on the UI. It also changes the text on another Text Block to indicate
processing has completed.
We have now successfully written a responsive multi-threaded WPF application. We
have done it using Delegates, Begin Invoke, End Invoke, Callback Methods, and
the WPF Dispatcher. Not a ton of work, but more than a little. However, this
traditional approach to multithreading can now be accomplished using a much
simpler WPF Asynchronous approach.
Asynchronous Event-Based Model
![asynchronous-Event-Based-Demo-in-vb.net.jpg]()
There are many approaches to writing asynchronous code. We have already looked
at one such approach which is very flexible should you need it. However, as of
.NET 2.0 there is what I would consider a much simpler approach and safer. The
System.ComponentModel. Background Worker (Background Worker) provides us with a
nearly fail safe way of creating asynchronous code. Of course the abstraction
which provides this simplicity and safety usually comes at a cost which is
flexibility. However, for the task of keeping a UI responsive while a long
process runs on the back-end it is perfect. In addition it provides events to
handle messaging for both tracking process, and cancellation with the same level
of simplicity.
Consider the following method which we have decided to spin off on a separate
thread so the UI can remain responsive.
Private Function SomeLongRunningMethodWPF() As String
Dim iteration As Integer = CInt(100000000
/ 100)
Dim cnt As Double =
0
For i As Long =
0 To 100000000
cnt = cnt + 1
If (i Mod iteration
= 0) And (backgroundWorker IsNot Nothing) AndAlsobackgroundWorker.WorkerReportsProgress Then
backgroundWorker.ReportProgress(i \ iteration)
End If
Next
Return cnt.ToString()
End Function
Notice
there is also some code to keep track of the progress. We will address this as
we get to it, for now just keep in mind we are reporting progress to background
Worker. Report Progress method.
Using the Background Worker and the event driven model the first thing we need
to do is create an instance of the Background Worker. There are two ways to
accomplish this task:
Create the Background Worker instance declaratively in your code.
Create the Background Worker in your XAML markup as a resource. Using this
method allows you to wire up your event method handles using attributes.
I will quickly
demonstrate the later method but for the remainder of the demo we will use the
declarative approach.
First you must reference the namespace for System.ComponentModel.
<Window x:Class="AsynchronousDemo"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:cm="clr-namespace:System.ComponentModel;assembly=System"
Title="Asynchronous
Demo" Height="400" Width="450">
Then you can
create an instance of the BackgroundWorker. Since there is no UI element you can
drop this XAML anywhere on the page.
<Window.Resources>
<cm:BackgroundWorker x:Key="backgroundWorker" WorkerReportsProgress="True"WorkerSupportsCancellation="False" />
</Window.Resources>
Declaratively
would can accomplish the same thing.
Private WithEvents backgroundWorker As New BackgroundWorker()
Next we need
something to call the long running process to kick things off. In our demo will
will trigger things with the click event of the button. Here's the method
handler that gets called and starts things off.
Private Sub WPFAsynchronousStart_Click(ByVal sender As System.Object,
ByVal e As System.Windows.RoutedEventArgs)
Me.wpfCount.Text
= ""
Me.wpfAsynchronousStart.IsEnabled
= False
backgroundWorker.RunWorkerAsync()
wpfProgressBarAndText.Visibility = Windows.Visibility.Visible
End Sub
Let's go
through what's happening in the button click event. First we clear out any text
that's in our Text Block used for displaying messages on the UI, and set Is
Enabled state of two buttons. Next we call RunWorkerAsync which fires off a new
thread and begins our asynchronous process. The event that is called by
RunWorkerAsync is Do Work. Do Work which is running on a new thread provides us
a place to call our long running method. RunWorkerAsync also has a second
overload which takes an object. This object can be passed to the Do Work method
and used in further processing. Note that we do not need any delegates here, and
we do not need to create any new threads ourselves.
When the button is clicked we are also capturing that event in a Storyboard
located in the XAML. This Storyboard Is triggering animation directed at a
ProgressBar which run until the asynchronous process has completed.
<StackPanel.Triggers>
<EventTrigger RoutedEvent="Button.Click" SourceName="wpfAsynchronousStart">
<BeginStoryboard Name="myBeginStoryboard">
<Storyboard Name="myStoryboard" TargetName="wpfProgressBar" TargetProperty="Value">
<DoubleAnimation From="0" To="100" Duration="0:0:2" RepeatBehavior="Forever" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</StackPanel.Triggers>
Private Sub backgroundWorker_DoWork(ByVal sender As Object, ByVal e As DoWorkEventArgs) HandlesbackgroundWorker.DoWork
Dim result As String
result = Me.SomeLongRunningMethodWPF()
e.Result = result
End Sub
There
are a few important things to note about Do Work. First, as soon as this method
is entered a new thread is spun off from the managed CLR thread pool. Next it is
important to remember that this is a secondary thread so the same rules apply
for not being able to update UI controls which were created on the primary
thread.
Remember in our long running process I noted that we were tracking progress?
Specifically, every 100 iterations of the loop we were calling:
backgroundWorker.ReportProgress(i \ iteration)
The method ReportProgress is wired up to call the BackgroundWorkers
ProcessChanged event.
Private Sub backgroundWorker_ProgressChanged(ByVal sender As Object,
ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles backgroundWorker.ProgressChanged
Me.wpfCount.Text
= CStr(e.ProgressPercentage)
& "%
processed."
End Sub
We are
using this method to update a Text Block with the current iteration count. Note
that because this method runs on the Dispatcher thread, we can update the UI
components freely. This is obviously not the most practical means of using the
Progress Changed event, however I wanted to simply demonstrate it's use. One
processing has completed in the Do Work method the dispatcher thread's
RunWorkerCompleted method is called. This gives us an opportunity to handle the
CompletedEventArgs.Result which was passed in from Do Work.
Private Sub backgroundWorker_RunWorkerCompleted(ByVal sender As Object, ByVal e AsRunWorkerCompletedEventArgs) Handles backgroundWorker.RunWorkerCompleted
wpfProgressBarAndText.Visibility = Windows.Visibility.Collapsed
Me.wpfCount.Text
= "Processing
completed. " & CStr(e.Result)
& "
rows processed."
Me.myStoryboard.Stop(Me.lastStackPanel)
Me.wpfAsynchronousStart.IsEnabled
= True
End Sub
In the
RunWorkerCompleted event we first hide the progress bar and progress bar status
text since our long running operation has completed. We can also enable the
start button so the demo can be run again. As noted previously we can access
these UI elements here because we are back on the primary thread (Dispatcher
thread).
The downloadable code also contains code which handles the Cancel sync method.
This demonstrates how you can give the user the ability to cancel a long running
process should they decide it's not worth waiting for. In most applications,
once the user starts a process they are stuck waiting for it to complete.
However, since this post has already run very long I have decided to not include
it here in the article.