Threading and WPF's Binding

Question

The Situation

I'm getting the following inconstant behavior on my application: One in about 20 executions, a WPFToolkit's DataGrid which is bound to a DataTable won't render all the rows, missing anything between 1 to 3 of the whole 4 rows that were expected.

Inner Workings

• The DataGrid is bound to a DataTable, D1, which is a property of a custom class, C1.
• When the user stimulates the view, we must retrieve the data from the back-end, which can take time. To do so, we create a thread (actually, we use BackgroundWorker for that but there seems to be no difference from using one or the other), which runs a method, M1, that opens the connection and request the data. The thread is used to avoid having an unresponsive application.
• M1 retrieves data and stores it on a DTO first. After that, he asks C1 to clear it's table. C1 does so (by calling a D1.Clear()) and raises NotifyPropertyChanged() (from the thread).
• M1 passes the new backend's DataTable to C1, which inserts row by row into D1. After finishing inserting the rows, C1 raises NotifyPropertyChanged(). The thread exits.

So, in other words, I clear the table, notify WPF, insert the data, notify WPF and exit.

In my view, as long as the last Notify is correctly consumed from the UI, it should always show all the rows.

Besides the DataTable, there are a large number of properties (mostly strings and int) being update and thus notified. We have not observed this behavior in any other case, only with the DataTable.

I know this goes deep into WPF mechanisms for binding, but I hope anyone can shed a light here. Any information about WPF binding or multi-threading with WPF is welcome.

Answer 1

DataTable pre dates WPF and thus doesn't implement INotifyCollectionChanged which is how WPF monitors for collection changes. You have two options:

1. Replace the existing DataTable with a new DataTable (after you have set the rows). Then fire the property changed notification.
2. Change from a DataTable to an ObservableCollection. The collection will fire a change notification anytime you change the list of items. (Note it will not fire if you change the contents of one of the items already in the list)

INotifyPropertyChanged notifies when the property has changed, not when the internal state (be it a property or collection) have changed. When you fire the Property Changed event WPF only rebinds the controls if the property is a different object from the last time it bound the data. This keeps it from refreshing the whole screen when you only change one property several layers down in an object graph.

Answer 2

Are you loading the new data into the same DataTable instance that's already bound to the DataGrid?

If so, then (a) every time you make a change to the DataTable from your background code, it's firing notifications from the wrong thread, which is a no-no; and (b) when you fire PropertyChanged at the end, the DataGrid might be clever enough to notice that the reference didn't actually change, so it doesn't need to do anything. (I don't know whether DataGrid tries to be that clever, but it wouldn't be unreasonable -- especially given the way WPF constructs views on top of collections -- and it might help explain the symptoms you're seeing.)

Try creating a new DataTable instance every time you need to refresh, and then when you're done populating that instance from your background thread, then assign the new (fully-populated) reference into your notifying property and fire PropertyChanged (and, of course, make sure to do the assignment+PropertyChanged from the UI thread).