Why use Dispatcher.BeginInvoke?

Question

I saw (and read) about using Dispatcher.BeginInvoke to ensure that UI updates happen in the UI thread. I understand this reasoning.

But I saw examples where in the "code-behind" view, the assignment of properties, such as the Text property for TextBlock, is declared safe only if you assigned it to this Dispatcher.BeginInvoke.

Question If I am manipulating any of the code in the code, it is not implied that it is controlled by the user interface flow (unless I use BackgroundWorker or an asynchronous service call).

In the examples mentioned above, other operations or asynchronous operations do not exist.

Question 2 If I have an asynchronous web service handler and I want to update the TextBlock line from this handler. Can I directly assign the Text property to TB, or should I use Dispatcher.BeginInvoke. Please note that I would not do this normally, as I prefer data binding to direct manipulation of interface elements like this.

Answer 1

You ask: "Is it not implied that it is controlled by the user interface flow." There is nothing to give an absolute guarantee, since Mike points out that non-private code access points can be called in a non-UI thread.

However, you can be sure that the event coming from the user interface elements will be in the user interface stream.

As for taking any precautions to ensure your code runs in the user interface thread, I don't think this is reasonable. What happens if you just let the code work fine. Perhaps this succeeds because you are not actually interacting with the user interface element, no harm. Alternatively, the code continues and throws an exception. This is bad?

Using the BeginInvoke precaution causes the calling code to execute asynchronously with the user interface code that was invoked. This can have unpredictable results, which can be a nightmare for tracking. Its much better to make your code behave predictably. Just throw away the error in the code, which should take responsibility for calling the user interface component in the correct thread. After all the code works as part of a user interface component, such as UserControl or Page .

Also consider that existing user interface elements in the Runtime, SDK, and toolkit do not perform thread failover.

Edit: answer to sassy adding a secondary question

This depends on the Async API used and which thread the API was called from.

When you call the async WebClient method from the user interface thread, the corresponding event also occurs in the user interface thread. Similarly, if you use the WCF service client class, the Completed event will be raised in the user interface thread if the asynchronous call operation is initially called in the user interface thread.

However, when using Begin / End pairs in the WebRequest component (or the standard service interface from WCF), callbacks will be executed in the background thread, regardless of the source thread used to start the operation.

Answer 2

If it is a protected method or event handler that responds only to user interface events, then you should be safe without a dispatcher. However, if you use code that may be exposed in some way, you better not make any assumptions about which thread it might execute.