Suspending GridDataBoundGrid painting

[Tim Lloyd]

I have a GridDataBoundGrid which is bound to a dataview and displays header information similar in style to the manner in which Outlook displays email headers.

The user highlights a header from the grid and then a number of actions can be performed on the real 'object' that the header represents by fetching it from the database etc. So far so good...

The action on the real data are performed in model dialogs, and when the changes have been saved, the data access layer trashes the underlying datatables that hold the header information and then repopulates the tables from the database with the up-to-date data.

The problem I am having is trying to find a way of temporarily suspending painting of the grid whilst the underlying datatable is cleared and repopulated, as this actions results in the grid going blank and then being refilled again. I cannot explicitly call a method on the grid as the clearing of the underlying datasource is indirect.

What I'm looking for is an event that I can possibly trap when the underlying datatable is cleared, so that I can call grid.BeginUpdate or what-have-you. This would prevent the grid from being redrawn. I have tried wiring into the ListChanged event of the dataview being used for the datasource, but the reset event only seems to be called after the fact, and not before.

Any help well appreciated.

Tim Lloyd.

[Administrator]

Can you have your data layer (or whatever initiates these actions) fire an event to which the grid can subscribe? This way you guarantee the event is fired exactly when you need it. And you would not have to directly call a grid method.

[Tim Lloyd]

Unfortunately the software architecture will not allow for this naturally.

Is there some event that is raised just before the underlying datasource changes and then after, so that I can stick my suspend and resume 'painting' code there?

Thanks, Tim.

[Administrator]

These events would have to come from the DataSource. So, if your DataSource is a DataView (DataTable), you might try the ColumnChanging/ColumnChanged or RowChanging/RowChanged events, but I am not sure this is what you need either as these will be fired for each change. I think you could grid.BeginUpdate in DataTable.RowChanging, but do not know of a good place to turn it back on. And you would probably want to finish several updates before you turn the drawing back on.

I don't know how the grid can provide the solution here. I think it will have to come from the datasource and the actions that initiate the external updating of the datasource, all of which occur transparently to the grid. The grid can probably stop drawing it self, but I do not know how it will know when to stop and when to start unless the datasource or the actions that start this change tell it. But I may be overlooking something...

[Tim Lloyd]

Clay,

I was originally a little concerned about the suggestion of introducing an event model in the data access layer due to the fact I thought it might adversely affect the coupling in my architecture. This was mainly down to a lack of experience of designing solutions. Your suggestion has proved to be quite inspirational and has led to learning more interesting stuff.

I've made an interface that describes a couple of basic events: 'updating' and 'updated', and have implemented this in my main dataaccess superclass and fired the events in the subclasses. I can now use the interface in a loosely coupled way with my grid-based control without polluting the archtiecture.

Thanks for the tip!

Tim.

PS. I am presemuing that calling Model.BeginInit() and Model.EndInit() are the appropriate methods to call when the events are raised that notify the subsriber that the underlying datasource is being churned???

[Administrator]

I think you may want to try BeginUpdate/EndUpdate calls on the grid in your event handlers. This will suspend the grid painting while the datasource is being changed. Depending upon what you are actually doing to the DataSource, there may be other steps that are needed.

[Tim Lloyd]

Clay,

I have gone with the Begin/EndUpdate() and also used Binder.Suspend/ResumeBinding(). This seems to have given good results. Is there something I should be aware of using this method?

I'm a little concerned that whatever method is used, if things go west inbetween the updating and update events the grid will be left in an indeterminate state.

Thanks, Tim.

[Administrator]

Probably about the only thing to be concerned about if there is some exception thrown during your updating that would prevent the EndUpdate code from being hit.