Which BeginUpdate() is best for performance

[Administrator]

I have a UserControl that uses a Grouping Grid and a "builder" type object that recreates the datasource, visible columns, grouping cols and summary cols when a user wants to see more data

As a workaround related to frozen cols not displaying correctly, we resize the first col down to 10 and then back to it''s correct size, but as a user you cna see this happening.

There appears to be lots of options to do with
GridControlBase.BeginUpdate and
GridControlBase.BeginUpdateModel.

What''s the preferred way (I''m think I''ve asked this before) - we''re doing this:
grid.GridControlBase.BeginUpdate(BeginUpdateOptions.None);
grid.GridControlBase.BeginUpdateModel(BeginUpdateOptions.None, true);

///LOTS OF UPDATES TO DATATABLE AND DISPLAY COLS

grid.GridControlBase.EndUpdateModel(false, true);
grid.GridControlBase.EndUpdate(true);

Does it make any difference if you use BgiunUpdateModel before BeginUpdate?

Thanks in advance

Jason

[Administrator]

Jason,

I worked on the frozen column issue you reported. Fix will be available with the next private build.

Regarding the BeginUpdate, best would be to do this:

                     this.groupingGrid1.GridGroupDropArea.BeginUpdate();
this.groupingGrid1.TableControl.BeginUpdate();

and then later

                     this.groupingGrid1.GridGroupDropArea.EndUpdate(true);
                    this.groupingGrid1.TableControl.EndUpdate(true);

We will also add a BeginUpdate / EndUpdate method for GridGroupingControl which you can then call instead of having to call BeginUpdate on both the TableControl and GroupDropArea.

Stefan

[Administrator]

One more thing: If you have a bunch of changes to the underlying data source, set Table.TableDirty = true before you make the changes.

Then the engine knows that the table is dirty anyway and will not try to do realtime inserts of new records added to the datasource. Instead it will just wait until the grid is displayed and then just loop through all records and categorize them.

Stefan

[Administrator]

Once again, thanks for all your help - it''s very useful

[Administrator]

I''ve tried the suggestions above and we''re still seeing repaints - fyi the GridGroupDropArea is not visible.

On creating the control our application remembers which groups were expanded and re-expands those. You can see the grid being drawn and actually watch the groups expanding.

Does it make any different that the have embedded your control into our own UserControl? Note is is multithread but we are using Invoke.

I noticed one post suggesting the use of Binder.SuspendBinding() but I can''t find the correct object to referece in the GroupingGrid - grid.GridTableModel.DataProvider is null

Would hooking into GridGroupingControl.Paint event comfirm how often it''s beign repainted?

Help would be greatly appreicated so that I can finally put this issue to sleep

Thanks in advance

Jason

[Administrator]

Hi Jason,

Binder.SuspendBinding() is defined in GridModelDataBinder - this is a helper class only used by the GridDataBoundGrid.

To achieve the same effect with GridGroupingControl you only need to set Table.TableDirty = true. Then subsequent ListChanged event from the datasource will be ignored and only when the grid gets repainted or some of its records are accessed from outside then the table gets categorized.

Calling groupingControl.TableControl.BeginUpdate() as mentioned before should prevent any further paints unless somewhere EndUpdate or CancelUpdate is called. Then the painting will resume. That should also work the same when the grid is used inside a UserControl.

Hooking into GridGroupingControl.Paint event will not help. You need to hook into GridGroupingControl.TableControl.Paint. There you can confirm how often it is repainted.

You can also check the call stack then and see why it is painted. Did GridGroupingConrol.Update() get called? Or CancelUpdate / EndUpdate maybe?

Stefan