3

When binding to a property in Silverlight 3 and 4, the Windows Phone 7 version silverlight and in WPF 3.5 and 4 will property change notifications always be marshalled to the UI thread? Are you aware of any scenario where I can not rely on that and would have to do the marshalling in my code?

bitbonk
  • 48,890
  • 37
  • 186
  • 278

2 Answers2

7

I did some experiments...

  1. INotifyPropertyChanged
    If you make a change to a property from a background thread, and it fires INotifyPropertyChanged from that background thread, and the property is databound, then...

    • WPF: it works (i.e. the databinder marshals it to the UI thread)
    • Silverlight5 and WinRT: it fails (i.e. the databinder doesn't marshal)
    • Phone: I assume it's the same as Silverlight, but haven't tried.
       

  2. DependencyProperty
    What if the property is a dependency property rather than INotifyPropertyChanged? What if you alter this property from a background thread? Well, I haven't done any experiments, but I read that it doesn't do any marshalling.

  3. INotifyCollectionChanged (e.g. ObservableCollection)
    If you add/remove elements in an ObservableCollection from a background thread, and the collection is databound to a listbox or similar, then what happens?

    • WPF: As of WPF4.5, you can use BindingOperations.EnableCollectionSynchronization(collection, new object()); and it will marshal correctly. However, prior to WPF4.5, it's as Pavlo said.
    • Silverlight, WinRT: again the same as Pavol said.
       
JDB
  • 25,172
  • 5
  • 72
  • 123
Lucian Wischik
  • 2,160
  • 1
  • 20
  • 25
2

Yes, collections. When you bind to an observable collection and you change it from a non-UI thread you will get an exception. You will have to marshal the collection change to the UI thread.

Pavlo Glazkov
  • 20,498
  • 3
  • 58
  • 71