Gets the Dispatcher this object is associated with.
Assembly: System.Windows (in System.Windows.dll)
Only the thread the Dispatcher was created on may access the object.
Silverlight Threading Concepts and Dispatcher
Silverlight supports several different concepts of threading. A consideration that overlies all discussion of threading in Silverlight is that for the most part Silverlight runs on a single main UI thread. One mistake you can make in Silverlight programming is to introduce something that blocks this main UI thread. Many Silverlight APIs, particularly those with reentrancy potential, include implementation details that make blocking the UI thread difficult or impossible to do. But there are still scenarios under which it is possible to block the UI thread and make the application unresponsive.
One way to mitigate a UI-thread-block situation is to create a separate thread and do work on it. However, a consequence is that under the Silverlight threading model, the separate worker thread cannot directly access the objects on the UI thread. In Silverlight, background threads can influence the UI asynchronously. For example, you could use a background worker thread to update an object data source, and that data source propagates a change that is accounted for in a Silverlight data binding.
One technique for creating a separate thread from the UI thread is to use the BackgroundWorker class. However, this technique is entirely unrelated to Dispatcher. It is instead a threading metaphor that can work generally with any CLR-level code, not just the UI base classes of Silverlight. With BackgroundWorker, you can use callbacks back to UI objects or any other listener object once the thread has completed. For more information. see BackgroundWorker.
Dispatcher supports a parallel technique to the BackgroundWorker technique. The model for Dispatcher is that you can add work item delegates to a dispatcher through a queue metaphor, and the work items are processed according to a system-determined priority. The Dispatcher threading model is based on the position of DependencyObject in the architecture; you can only use Dispatcher techniques on a DependencyObject. Many Silverlight types (particularly those that come from System.Windows assembly) are derived from DependencyObject, Generally this means the relevant type is associated with UI presentation in some way, and is not a type for general programming logic and flow, raw data, CLR language concepts, and so on.
Before you do anything with the Dispatcher threading technique, you should call Dispatcher.CheckAccess (or you can instead call DependencyObject.CheckAccess before getting the Dispatcher). If either CheckAccess returns false, this means that you are in a state where attempting an operation that would be legal from the UI thread is now illegal from your state. Therefore you should instead use the Dispatcher and put something in the queue with BeginInvoke.
Silverlight Dispatcher and WPF Dispatcher
If you are familiar with the WPF implementation of Dispatcher, there are some notable differences in the Silverlight implementation.
Silverlight does not expose a DispatcherObject class. In WPF, the DispatcherObject is the discrete exposure of how WPF handles threading a possibly wider range of objects, not just DependencyObject. In Silverlight, the Dispatcher and threading related capabilities are exposed in the DependencyObject API instead.
Silverlight does not automatically provide new Dispatcher instances. You can get provided Dispatcher references any time you need them, by calling , so creating a separate Dispatcher is not necessary. In contrast, WPF has a CurrentDispatcher static API that potentially creates new instances, for cases that are not DependencyObject and are instead a different DispatcherObject extension.
The Dispatcher in Silverlight does not have synchronous Invoke methods.
There is no concept of settable DispatcherPriority in the Silverlight Dispatcher. The system is responsible for prioritizing both its own threads and any user code calls into the threading model.
Because Silverlight's concept of Dispatcher threading is always tied to a DependencyObject, many of the WPF Dispatcher APIs that are related to extension of Dispatcher threading do not exist in Silverlight. This includes:
Events and status properties that track Dispatcher object lifetime
Exception handling hooks at the Dispatcher level
Thread control APIs such as Run
Support classes for these scenarios, for example DispatcherFrame
Callable API on DispatcherOperation (the class exists in Silverlight for internal support but has no callable API)
The following code example demonstrates how to use this property and the returned Dispatcher.
Private Delegate Sub AddTextDelegate(ByVal p As Panel, ByVal text As String) Private Sub AddText(ByVal p As Panel, ByVal text As String) p.Children.Clear() Dim t As New TextBlock t.Text = text p.Children.Add(t) End Sub Private Sub TestBeginInvokeWithParameters(ByVal p As Panel) If p.Dispatcher.CheckAccess() _ Then AddText(p, "Added directly.") _ Else p.Dispatcher.BeginInvoke(New AddTextDelegate( _ AddressOf AddText), p, "Added by Dispatcher.") End Sub
For a list of the operating systems and browsers that are supported by Silverlight, see Supported Operating Systems and Browsers.