Access UI element from non UI thread

Question

I've got small WPF / MVVM example project with two visual elements (a ComboBox and a simple TextBlock). Both elements are bound to a property of my ViewModel:

Properties MainViewModel.cs

public const string WelcomeTitlePropertyName = "WelcomeTitle";
private string _welcomeTitle = string.Empty;

public string WelcomeTitle
{
    get{ return _welcomeTitle;}
    set
    {
        _welcomeTitle = value;
        RaisePropertyChanged(WelcomeTitlePropertyName);
    }
}

public const string PositionsPropertyName = "Positions";
private ObservableCollection<int> _positions = new ObservableCollection<int>();

public ObservableCollection<int> Positions
{
    get{ return _positions; }

    set
    {
        _positions = value;
        RaisePropertyChanged(PositionsPropertyName);
    }
}

Bindings MainWindow.xaml

<StackPanel>
    <TextBlock Text="{Binding WelcomeTitle}"/>
    <ComboBox ItemsSource="{Binding Positions}" />
</StackPanel>

Now I change both properties from a non UI thread like this (which is not allowed, as far as I know it):

    System.Threading.ThreadPool.QueueUserWorkItem(delegate
    {
        int i = 0;
        while(true)
        {
            Positions.Add(i); // Solution 1: this throws NotSupportedException
            WelcomeTitle = i.ToString(); // Solution 2: this works

            i++;
        }
    }, null);

Question:

Why does solution 1 throw a NotSupportedExpection (not allowed to change collection from non dispatcher thread) while solution 2 works as desired?

Answer 1

The simple Property binding is automatically dispatched to the GUI thread by WPF and can be changed from a non-UI thread. However, this is NOT true for collection changes (ObservableCollection<> BindingList<>). Those changes must happen the UI thread the control was created on. If I remember correctly, this was not true (solution 2 did not work also) in the early years of WPF and .NET.

Answer 2

Now I change both properties from a non UI thread like this (which is not allowed, as far as I know it)

In general, changing property values is perfectly fine no matter what thread you are on. Problems and restrictions may come up when changing a property has an "interesting" side effect.

In this case both of the properties being changed produce interesting side effects, and the difference in observed behavior is due to these side effects being handled (from framework code, which you do not get to see directly) in different ways.

Why does solution 1 throw a NotSupportedExpection (not allowed to change collection from non dispatcher thread) while solution 2 works as desired?

When a binding source's properties are changed the WPF binding system responds by making the corresponding updates to the UI; however, when the changes are made from a background thread then the binding system's event handler will also run in the background thread and will not be able to update the UI directly. This is true for both the cases in question here.

The difference is that for "simple" property value changes the binding system automatically detects that it's not responding to the change on the UI thread and dispatches the UI changes to the correct thread using Dispatcher.Invoke, but when the observable collection is modified this dispatch does not happen automatically. The result is that the code that updates the UI runs on the background thread and an exception is thrown.

The solution

There are two things either one of which can solve this problem:

1. Make the property change in the UI thread directly

   If the change is made on the UI thread then any PropertyChanged handlers will also run on the UI thread, so they will be free to make any UI changes they want. This solution can be enforced in your own code and will never result in a problem, but if no UI changes are required the extra work of dispatching to the UI thread will have been done for no benefit.

2. Make sure the PropertyChanged handler dispatches any UI-related changes to the UI thread

   This solution has the benefit that it only dispatches work on demand, but also the drawback that the event handler (which might not be your own code) must be explicitly programmed to make the dispatch. .NET already does this for plain properties, but not for ObservableCollection. See How do I update an ObservableCollection via a worker thread? for more information.