All WPF applications start out with two important threads, one for rendering and one for managing the user interface. The rendering thread is a hidden thread that runs in the background, so the only thread that you ordinarily deal with is the UI thread. WPF requires that most of its objects be tied to the UI thread. This is known as thread affinity, meaning you can only use a WPF object on the thread on which it was created.(this is golden rule for UI threading….!!!! ) Using it on other threads will cause a runtime exception to be thrown. More over that the WPF threading model interoperates well with Win32 APIs. This means that WPF can host or be hosted by any HWND-based API (Windows Forms, VB 6.0 , MFC, or even Win32).
Dispatcher class is aa prioritized message loop for WPF applications which handled thread affinity . Typically WPF app have a single Dispatcher object (and therefore a single UI thread) that all user interface work is channeled through.
Unlike typical message loops, each work item that is sent to WPF is sent through the Dispatcher with a specific priority. This allows for both ordering of items by priority and deferring certain types of work until the system has time to handle them. (For example, some work items can be deferred until the system or application is idle.) Supporting item prioritization allows WPF to allow certain types of work to have more access, and therefore more time on a thread, than other work.
Later in this article I will demonstrate that the rendering engine is allowed to update the user interface at a higher priority than the input system. This means that animations will continue to update the user interface no matter what the user is doing with the mouse, keyboard, or ink system. This can make the user interface appear more responsive. For example, let’s assume you were writing a music-playing application (like winamp ). You would most likely want the information about the music playing (including the progress bar and other information) to show up whether the user was using the interface or not. To the user, this can make the interface appear more responsive to what they are most interested in (listening to music, in this case).
In addition to using the Dispatcher’s message loop to channel items of work through the user interface thread, every WPF object is aware of the Dispatcher that is responsible for it (and therefore, the UI thread that it lives on). This means that any attempts to update WPF objects from secondary threads will fail. This is the responsibility of the DispatcherObject class
In the hierarchy of classes in WPF, most derive centrally from the DispatcherObject class (through other classes).
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:
1) to provide access to the current Dispatcher that an object is tied to
2) and provide methods to check (CheckAccess) and verify (VerifyAccess) that a thread has access to the object (derived from DispatcherObject).
The difference between CheckAccess and VerifyAccess is that CheckAccess returns a Boolean value that represents whether the current thread can use the object and VerifyAccess throws an exception if the thread does not have access to the object. By providing this basic functionality, all the WPF objects support being able to determine whether they can be used on a particular thread—specifically, the UI thread. If you are writing your own WPF objects, such as controls, all methods you use should call VerifyAccess before they perform any work. This guarantees that your objects are only used on the UI thread.
public class MyWpfObject : DispatcherObject
public void DoSomething()
// Do some work
public void DoSomethingElse()
// Something, only if called
// on the right thread
With this in mind, be careful to be on the UI thread when calling any DispatcherObject-derived object such as Control, Window, Panel, and so on. If you make a call to a DispatcherObject from a non-UI thread, it will throw an exception. Instead, if you are working on a non-UI thread, you’ll need to use the Dispatcher to update DispatcherObjects
Sr. Programmer Analyst