Updating a User Interface from a Background Process
- Why Do We Need Background Processing?
- Running a Process on Another Thread
- The Single-Threaded Example
- Creating a Multithreaded Version
- Working with the User Interface from Another Thread
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In any field, including programming, some problems commonly appear, and the solutions to those problems are often the same every time. Christopher Alexander first introduced the term design patterns in the context of architecture (building architecture that is, not systems architecture), to represent the idea that the same general problems are encountered in many different architectural designs and that these general problems share the same solutions. This is hardly a debatable concept: Across thousands of architectural designs, there is a certain amount of repetition. Based on either experience or academic knowledge, many different architects will solve the same problems in the same way.
It wasn't long before this idea was applied to other fields, including the design and implementation of computer systems, where it has found an enthusiastic response from many different architects and developers. The book Design Patterns, by Gamma, Helm, Johnson, and Vlissides (nicknamed the "Gang of Four" by some) presented an overview of this idea, along with a detailed description of 23 specific design patterns. Now, each of these patterns describes a general problem and a general way in which that problem could be handled, but all do so at a very high level and in a language-independent fashion. For the most part, design patterns tend to stay away from implementation. They exist at a level above the specific language or platform that you are working on. However, this concept of generic solutions for generic problems can be applied at whatever level of detail you want.
With these concepts in mind, you can see that many of the more common problems or requirements encountered in your own projects are really generic design issues for which the solution is the same, regardless of which project it occurs in. The wonderful thing about these generic problems is that, if you recognize them, then you can find and reuse the same solution.
In this article, I take a look at a very common problem that is encountered when writing Windows applications, and then I show you a solution implemented using .NET. The generic requirement or problem is background processing, the need to perform tasks while a user continues to interact with your program's user interface.
Why Do We Need Background Processing?
The primary aspect by which a user will judge your application is its interface. If that interface appears to hang, runs slowly, or otherwise forces users to wait, they will think poorly of your program. This is a well-known UI concept, in which the perceived speed of a system is often more important than its real speed, and it forces you to use some form of background processing. Consider a sample application that scans the user's hard drive for Windows Media Audio (WMA) files, lists them on the screen, and then lets the user browse, select and play them. Without any form of background processing, the system would perform the scan as a dedicated task, which would be the fastest method, but it would force the user to wait until the scan was complete to start interacting with the program (see Figure 1).
){kind=link}
Figure 1 Without background processing, the user has to wait whenever the program is working on a task.
Alternatively, and certainly what the user would expect, the scan could run in the background (see Figure 2), filling in the list a little more slowly than in the dedicated example, but not requiring any user wait time.
){kind=link}
Figure 2 Processing the task in the background means that the user experiences the minimum amount of delay.
So, the general issue is that you need to maintain a responsive user interface even when you have one or more processing tasks to perform. The general solution (and you will see this being done in almost every piece of commercial software that supports a user interface) is to run those processing tasks in the background while still allowing the user to interact with the system. Now, the trick is how to accomplish this using Visual Basic .NET. The remainder of this article details the implementation of both a background process and the technique required to have that background process update the user interface.