Refresh issues with GridDataBoundGrid bound to Custom Collection

[Ramya Modukuri]

I have a custom collection called AccountCollection that implements IList, IBindingList and IListSource. The collection contains Account objects. Each Account is a simple class with 3 properties - a string AccountId, an int Total, and an AccountCollection (because each Account can have Sub Accounts of the same type). I hydrate this collection with some accounts (e.g. "AA", "BB" etc.) and add 2 sub accounts to each account (e.g. "AA" has sub accounts "aa001", "aa002"; "BB" has "bb001", "bb002" etc.). I bind my GDBG to this collection, and set up a GridHierarchyLevel for the relation. Additionally, I have a timer that increments the Total for each sub account and aggregates the subaccount totals into the parent account Total, within a BeginUpdate(Invalidate), EndUpdate block. The issue I''m having is that if I have 5 accts, and none of them are expanded, all 5 rows are refreshed. However, if I expand the first acct to display its sub accts, the grid still only refreshes the first 5 rows. Therefore, the last 2 acct rows don''t refresh. I suspect I''m doing something wrong in the RaiseListChangedEvent method in my Custom collection. I''m attaching the test application. Please advise. Regards, Ramya AccountTest_6565.zip

[Administrator]

I think to get this to work in a GridDataBoundGrid, you will have to call grid.Refresh to force everything to refdraw after an update.

private void UpdateDataSource()
{
	_grid.BeginUpdate();//(BeginUpdateOptions.Invalidate);
	foreach (Account acct in _accounts)
	{
		foreach(Account subAcct in acct.Children)
		{
			if(subAcct.Total < 1000)
			{
				subAcct.Total++;
				acct.Total++;
			}
		}
	}
	_grid.EndUpdate();//(true);
	_grid.Refresh();
}

[Ramya Modukuri]

Yes, I''m aware of Grid.Refresh, and this is what we''re currently using in our actual application.

However, our performance analyses show that grid.Refresh is quite an expensive operation. We therefore want to find a more efficient alternative. Do you have any idea why it doesn''t work using this approach?

[Administrator]

In a GridDtaBoundGrid, the grid does not respond to IBindingList.ListChanged events except on the parent level. That is why it is not working. The GridDataBoundGrid does not track the information necessary to map the changed item to the proper hierarchy level/child list.

If you want the nested tables to refresh themselves based on ListChanged events, then you would have to use a GridGroupingControl.

[Ramya Modukuri]

Hi, We''ve decided to revisit this issue, so I tried out what you suggested - using a GridGroupingControl to display the hierarchical data. I still bind the control to a custom collection. While I no longer have to call gridCtrl.Refresh(), my performance analysis shows that the overall performance is now worse than it was before (with the GridDataBoundGrid and a call to Refresh whenever the underlying data changes). My question is, is the GridDataBoundGrid more efficient than the GridGroupingControl for situations where the grid is bound to a custom control and where updates are frequent (underlying data changes once a second)? I am attaching the test project (the AccountTest.cs uses the GridDataBoundGrid, and AccountTestNew.cs uses the GridGroupingControl). Any help on this will be greatly appreciated. FYI, I''m using version 2.1.0.9 with VSNET2003 and Fmwk 1.1. Regards, Ramya

AccountCollection.zip

[Administrator]

The GridDataBoundGrid can be more efficient than a GridGroupingControl as the GridGroupingCOntrol has more functionality in it. It does things like index the data in a balance tree structure to enable its support for grouping, summaries etc. The GridDataBoundGrid does not have this type of infrastructure.

In your test, you are essentially changing the data in all rows every second. This effectively means that the whole grid has to be redrawn every second. So, both grids are redrawing every second, and in addition, the GridGroupingControl is also responding to child list''s ListChnaged events that the GridDataBoundGrid is ignoring. So, this is likely why you see a higher work load in the GridGroupingControl.

In later releases than 2.1.0.9, there are additional optimizations that you cna use to try to reduce this load (like ggc.BeginUpdate/EndDate available in 3.3), but if in fact the whole grid is being forced to redraw because all the data is changing, then it is likely that the GridDataBoundGrid will be more effiecient as it is not doing the same work.

I am not sure how you are measuring load, but I did run your samples just looking at the TaskManager performance. With the GGC, I saw a 4% load most of the time with occasional spikes to 10-12% just letting your sample update. With the GDBG, the most of the time load was 2-3% with occasional spikes to 10-12%. This was with 3.3 and using BeginUpdate/EndUpdate and setting grid.Table.TableDirty = true.

[Ramya Modukuri]

Thanks for your prompt response.

Yes, the GGC certainly seems to be a more complex control than the GDBG.

In my actual application, I have anywhere between 4 - 15 columns visible, and at any given time, atleast one (and potentially all) of them will be updated each second for all the rows. So, the the test case is not too far off the mark.

I''m using Rational Quantify to analyze the performance. The time for each GridControlBase.OnPaint is approx. 36ms for the GDBG vs. 124ms for the GGC, which is quite a significant difference.

Also, since this is a small part of a pretty large project, we won''t be upgrading to a new version anytime soon, and I need a more efficient alternative for now.

Having said that, I have a couple of questions:
1. Is there a way in the GGC in 2.1 to invalidate just the modified cells? (i tried a gridCtrl.TableControl.BeginUpdate(Invalidate)/End
Update, but the performance characteristics didn''t really change.
2. Can I implement a hierarchical view (it''s ok if it''s not databound) with the GridControl? If so, are there any samples for this?
3. Are there any other controls besides these three that can be used for this?

Thanks,
Ramya