I''m trying to optimise the way I use the GridDataBoundGrid (version 188.8.131.52). I have a background
thread updating data held in a custom collection that fires ListChanged events when modified. The
grid is bound directly to this collection.
The background thread updates the collection every half second firing events immediately before and
after the update. I have tried various things including event handlers that SuspendBinding on the
grid before an update and resume it afterwards. Because the events are fired in a background thread
I have to do an Invoke and call Suspend/Resume binding from the GUI thread.
The grid is configured to with UseListChangedEvent and ForceUpdateAfterListChangedEvent set to
The dataset contains approximately 70 columns and 150 rows.
The performance is nowhere near as good as the GridPerf sample and I''m trying to ascertain why.
I have to use a custom collection as I have a hierarchical grid*. If I were using ADO.Net I would
call BeginLoadData() on my DataTable before updating it. What does the GridDataBoundGrid do when
this method is called that enables such good performance with this approach or is this to do with
the way DataTable works?
Please do you have any suggestions or examples for how to get best the performance from the grid
with a custom dataset that is updated in the background?
* with some particular requirements that can''t be met using DataTables.
ADAdministrator Syncfusion Team December 3, 2004 05:41 PM
The BeginLoadData suspends notification of data changes in the DataTable. Thismeans that event listeners like the grid, do not not hear change events, and do not respond to them.
One thing you might try is to batch the updates on the background thread. Then every so often (maybe every 100 - 200 - 300 msecs) raise an event that updates the datasource from the cached updates on the UI thread. This will avoid constant swicthing to the UI thread to respond to every listchanged event for individual updates from the background thread. This may give you better through put.