DependencyObject.Dispatcher Property

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Gets the Dispatcher this object is associated with.

Namespace:  System.Windows
Assembly:  System.Windows (in System.Windows.dll)


<EditorBrowsableAttribute(EditorBrowsableState.Advanced)> _
Public ReadOnly Property Dispatcher As Dispatcher
public Dispatcher Dispatcher { get; }

Property Value

Type: System.Windows.Threading.Dispatcher
The Dispatcher this object is associated with.


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.

If CheckAccess instead returns true, then using a Dispatcher to invoke the action is not necessary. You should instead perform the operation against the relevant DependencyObject directly.

For more information on how to use Dispatcher and threading for UI, see Dispatcher.

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 DependencyObject.Dispatcher, 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

    • DispatcherHooks

    • 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)
    Dim t As New TextBlock
    t.Text = text
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
private delegate void AddTextDelegate(Panel p, String text);

private void AddText(Panel p, String text)
    p.Children.Add(new TextBlock { Text = text });

private void TestBeginInvokeWithParameters(Panel p)
    if (p.Dispatcher.CheckAccess()) AddText(p, "Added directly.");
    else p.Dispatcher.BeginInvoke(
        new AddTextDelegate(AddText), p, "Added by Dispatcher.");

Version Information


Supported in: 5, 4, 3

Silverlight for Windows Phone

Supported in: Windows Phone OS 7.1, Windows Phone OS 7.0


For a list of the operating systems and browsers that are supported by Silverlight, see Supported Operating Systems and Browsers.