MSDN Magazine - October 2007 - (Page 67)

The Threading Model has access to the object (derived from DispatcherObject). Object All WPF applications start out with two important The difference between CheckAccess and VerifyAccess threads, one for rendering and one for managing the user is that CheckAccess returns a Boolean value that repinterface. The rendering thread is a hidden thread that resents whether the current thread can use the object DispatcherObject runs in the background, so the only thread that you ordiand VerifyAccess throws an exception if the thread does narily deal with is the UI thread. WPF requires that most not have access to the object. By providing this basic DependencyObject of its objects be tied to the UI thread. This is known as functionality, all the WPF objects support being able thread affinity, meaning you can only use a WPF object to determine whether they can be used on a particular on the thread on which it was created. Using it on other thread—specifically, the UI thread. If you are writing Visual threads will cause a runtime exception to be thrown. your own WPF objects, such as controls, all methods Note that the WPF threading model interoperates well you use should call VerifyAccess before they perform with Win32®-based APIs. This means that WPF can any work. This guarantees that your objects are only host or be hosted by any HWND-based API (Windows used on the UI thread, as shown in Figure 2. Forms, Visual Basic®, MFC, or even Win32). With this in mind, be careful to be on the UI thread Figure 1 Dispatcher The thread affinity is handled by the Dispatcher Object Derivation when calling any DispatcherObject-derived object such class, a prioritized message loop for WPF applications. as Control, Window, Panel, and so on. If you make a Typically your WPF projects have a single Dispatcher object (and call to a DispatcherObject from a non-UI thread, it will throw an therefore a single UI thread) that all user interface work is chan- exception. Instead, if you are working on a non-UI thread, you’ll neled through. need to use the Dispatcher to update DispatcherObjects. Unlike typical message loops, each work item that is sent to WPF is sent through the Dispatcher with a specific priority. This allows Using the Dispatcher for both ordering of items by priority and deferring certain types The Dispatcher class provides a gateway to the message pump in of work until the system has time to handle them. (For example, WPF and provides a mechanism to route work for processing by the some work items can be deferred until the system or application is UI thread. This is necessary to meet the thread affinity demands, idle.) Supporting item prioritization allows WPF to allow certain but since the UI thread is blocked for each piece of work routed types of work to have more access, and therefore more time on a through the Dispatcher, it is important to keep the work that the thread, than other work. Dispatcher does small and quick. It is better to break apart larger Later in this article I will demonstrate that the rendering engine is allowed to update the user interface at a higher priority than the Figure 2 Using VerifyAccess and CheckAccess input system. This means that animations will continue to update public class MyWpfObject : DispatcherObject the user interface no matter what the user is doing with the mouse, { keyboard, or ink system. This can make the user interface appear public void DoSomething() { more responsive. For example, let’s assume you were writing a muVerifyAccess(); ® sic-playing application (like Windows Media Player). You would // Do some work most likely want the information about the music playing (includ} ing the progress bar and other information) to show up whether public void DoSomethingElse() the user was using the interface or not. To the user, this can make { the interface appear more responsive to what they are most interif (CheckAccess()) { ested in (listening to music, in this case). // Something, only if called In addition to using the Dispatcher’s message loop to channel // on the right thread } items of work through the user interface thread, every WPF ob} ject is aware of the Dispatcher that is responsible for it (and there} fore, the UI thread that it lives on). This means that any attempts to update WPF objects from secondary threads will fail. This is Figure 3 Updating UI with NonUI Thread—The Wrong Way the responsibility of the DispatcherObject class. DispatcherObject In the hierarchy of classes in WPF, most derive centrally from the DispatcherObject class (through other classes). As shown in Figure 1, you can see that the DispatcherObject virtual class is sandwiched just below Object in the hierarchy of most WPF classes. The DispatcherObject class has two chief duties: to provide access to the current Dispatcher that an object is tied to and provide methods to check (CheckAccess) and verify (VerifyAccess) that a thread // The Work to perform on another thread ThreadStart start = delegate() { // // This will throw an exception // (it’s on the wrong thread) statusText.Text = “From Other Thread”; }; // Create the thread and kick it started! new Thread(start).Start(); october2007 67

Table of Contents Feed for the Digital Edition of MSDN Magazine - October 2007

Cover Contents Toolbox CLR Inside Out Basic Instincts Data Points Cutting Edge Pooled Threads WPF Threads Parallel Linq Parallel Performance Mobile Apps Test Run Foundations Windows with C++ Netting C++ .NET Matters { End Bracket } Net Nuptials

MSDN Magazine - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.