Dispatcher A good tool for threading in WPF Part -I

Hi friends,

In my career I  had come across many good looking desktop application in which user do some click or tap his/her figure on screen for certain task and it becomes  “not responding  status”  due to long running  tasks. This type of Painful user experience makes application unsuccessful.

Means responsiveness of your application make difference. Hence developer should use threading in their application with some care to make more responsive application. In older .net (winform ) we have background work and threadpool to do  threading. Now in WPF we got another feature named dispatcher which makes your threading  work more easy hence you can make your WPF application better when you have  long running task in you  WPF screen .

 Long-running processes are involved—whether getting large results from a database, making async Webservice calls, or any number of other potentially intensive operations makes our application more unresponsive so we need to make it responsive to make your end  users much happier in the long run. But before you can start using an async programming model in your WPF app, it is important that you understand the WPF threading model. In this blogI will not only introduce you to that threading model, but I'll also show you how the Dispatcher-based objects work and explain how to use the BackgroundWorker so that you can create compelling and responsive user interfaces(i  will do in next blog)

Threading Model of WPF

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

Dispatcher Object

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()

{

VerifyAccess();



// Do some work

}



public void DoSomethingElse()

{

if (CheckAccess())

{

// 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

 now it is late night so  further details  i will discuss in my  next post..

compile by
Divyang Panchasara
Sr. Programmer Analyst
Hitech OutSourcing