The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

DependencyObject.Dispatcher Property

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

Gets the Dispatcher this object is associated with.

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

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.

Windows Phone Threading Concepts and Dispatcher

On Windows Phone, there is a single thread that updates the user interface of the application. One mistake you can make in Windows Phoneprogramming is to introduce something that blocks this main UI thread. Many Windows Phone 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 Windows Phonethreading model, the separate worker thread cannot directly access the objects on the UI thread. In Windows Phone, 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 Windows Phonedata 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 Windows Phone. 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 Windows Phonetypes (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.

Windows Phone Dispatcher and WPF Dispatcher

If you are familiar with the WPF implementation of Dispatcher, there are some notable differences in the Windows Phoneimplementation.

  • Windows Phonedoes 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 Windows Phone, the Dispatcher and threading related capabilities are exposed in the DependencyObject API instead.

  • Windows Phone 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 Windows Phonedoes not have synchronous Invoke methods.

  • There is no concept of settable DispatcherPriority in the Windows PhoneDispatcher. The system is responsible for prioritizing both its own threads and any user code calls into the threading model.

  • Because the Windows Phone 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 Windows Phone. 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 Windows Phone for internal support but has no callable API)

The following code example demonstrates how to use this property and the returned Dispatcher.

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.");

Windows Phone OS

Supported in: 8.1, 8.0, 7.1, 7.0

Windows Phone