DataGrid not updating when it bind to DataTable.DefaultView

Hi There, We are using Feb. 11, 2013 nightly build and we found the following problem:

1) Binding the DataGrid with DataTable.DefaultView

2) A work thread is updating the DataTable

3) For the existing rows, if any cell value changed, it will update, which is good.

4) If the work thread add new rows to the DataTable, then the new row will not shown on the DataGrid. This is very big problem for us, can you fix them asap?

By the way, did you have any chance to work on the efficiency problem on huge datatable, see the thread. We also need this to be fixed since we need to release it in 2 months.

Thanks Gordon

Hello Gordon

Unfortunately it seems that this will not work using a thread. The DataGrid is already listening to the correct events, but when updating the DataTable in a different thread, the DataGrid does not receive the events. This is something we can not work around. To resolve this, you can either update the DataTable without using a worker thread, or you can marshal the update operation back to the UI thread.

I have looked into the DataGrid performance and roughly worked out the main areas that are slowing things down. I hope to implement performance improvements within the next 2 weeks.

Jason Fauchelle

Thanks Jason,

I would admit this is very disappointing news, since I remember it was working before.

Even though the work thread update the Table, but I can still subscribe it to the RowChanged event, which includes the row added event. When you say the DataGrid listen to the correct event, does it listen to the RowChanged event? The only concern here is that this event is fired up too often, and it will contribute to the slowness of the DataGrid, when the table is too large (too many rows and columns. My solution for this is to use a thread to handle this and skip most of events)

We have to use work thread is to make sure it will not block the main UI thread.

All other DataGrid, including the WPF's own or DataGridView in WinForm will work in this situations.

Thanks

Gordon

Hello Gordon

The event we listen to is ListChanged. This provides anything we need to listen to for both BindingList and DataView. I've looked into it further and still cannot find out why the event is not received when it is updated in a thread, but works perfectly fine when not using a separate thread.

I had a look at using the RowChanged event, and it turns out this one does not have the same problem as the ListChanged event. However, there is a problem with this: The event handler of course needs to access and modify parts of the UI in order to update it (show the new rows). But this can not be done because the thread that invoked the event handler (the worker thread) is different to the thread that created the DataGrid (the UI thread). As soon as the event handler tries to update the UI thread, the program crashes. This is just how WPF works. Even if the ListChanged event was working, it would have the same problem.

It is generally recommended that you never modify any part of the UI, including anything the UI is bound to in a different thread. Although it works in some cases, it can cause unexpected behavior or cause exceptions. Even worse: these may only occur on rare occasions which go undetected until your clients notice them.

WPF best practice is to use worker threads for bulk computations, and then marshal the result back to the UI thread.

I tried the same thing with the standard WPF DataGrid and also found that the UI does not show the rows when they are added in a worker thread. Only when sorting a column do they appear. When trying to resize the window, the application crashes.

So to solve this issue, make sure the DataTable is updated in the UI thread. You can still use a worker thread to do heavy logical operations to help the performance of the application.

Jason Fauchelle