We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

Which BeginUpdate() is best for performance

Thread ID:

Created:

Updated:

Platform:

Replies:

18496 Sep 1,2004 07:35 AM Sep 15,2004 07:11 AM Windows Forms 5
loading
Tags: Grouping
Administrator [Syncfusion]
Asked On September 1, 2004 07:35 AM

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 [Syncfusion]
Replied On September 2, 2004 10:10 AM

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 [Syncfusion]
Replied On September 2, 2004 10:12 AM

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 [Syncfusion]
Replied On September 3, 2004 06:38 AM

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

Administrator [Syncfusion]
Replied On September 15, 2004 06:47 AM

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 [Syncfusion]
Replied On September 15, 2004 07:11 AM

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

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;