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

Based on Asti's third point, I often come across a cross-thread PropertyChanged scenario and have a base view model for that. The view model is based on the PRISM NotificationObject, but of course you can implement the INotifyPropertyChanged interface directly if you do not wish to use PRISM. Works just as well for Silverlight if you ever use it.

namespace WPF.ViewModel
{
    using System.Windows;
    using System.Windows.Threading;

    using Microsoft.Practices.Prism.ViewModel;

    /// <summary>The async notification object.</summary>
    public abstract class AsyncNotificationObject : NotificationObject
    {
        #region Constructors and Destructors

        /// <summary>Initializes a new instance of the <see cref="AsyncNotificationObject"/> class.</summary>
        protected AsyncNotificationObject()
        {
            Dispatcher = Application.Current.Dispatcher;
        }

        #endregion

        #region Properties

        /// <summary>Gets or sets Dispatcher.</summary>
        protected Dispatcher Dispatcher { get; set; }

        #endregion

        #region Methods

        /// <summary>The raise property changed.</summary>
        /// <param name="propertyName">The property name.</param>
        protected override void RaisePropertyChanged(string propertyName)
        {
            if (Dispatcher.CheckAccess()) base.RaisePropertyChanged(propertyName);
            else Dispatcher.BeginInvoke(() => base.RaisePropertyChanged(propertyName));
        }

        #endregion
    }
}

Answer 2

1. Instead of directly binding the DataTable, always bind the DataView of the table. The view versions of the table, DataView has ListChanged and DataRowView has PropertyChanged.
2. WPF does support updates right down to the row level. If you change a row value, it will certainly propagate immediately.
3. PropertyChanged is not thread safe. You cannot cause any change to trigger PropertyChanged on a different thread. It must be done on the dispatcher, so have the change go through the dispatcher. E.g., Instead of Model.Data = newData, you should use Dispatcher.Invoke(new Action(model => model.Data = newData), Model) or similar.

Answer 3

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 4

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