List view

ajj3085 posted on Friday, October 12, 2007

Hi,

I have a list, LineItemsInternal, which is used to store my line items.  Line items may contain other line items as well.  This internal list is fine for my program, but to display on a grid I need to flatten out this line item hierarchy.

To do so, I have a LineItems class, which holds a list of the flattened hierarchy.  It delegates calls to the Internal list, and rebuilds the flattened list by listening to the Internal list's ListChanged event.  Also, RaiseListChangedEvents is on the Internal list is kept in sync with the view's flattened list. 

Now, I'm trying to improve performance of databinding.  To do so, I turn off RaiseListChangedEvents for the binding source.  This doesn't help much, because the BS is still being told of all the list changes, which isn't necessary (because I call ResetBindings after list change operation is complete).  So my next step to speed things up is to set RaiseListChangedEvents on the flattened list itself. 

The problem is that the flattened list is never rebuild, because rebuilding the flattened list is only done when the Internal list raises its event.

So, my first thought was to add a flag to track if the two lists get out of sync; because the Internal list is not seen at all, the view list handles the tasks of adding or removing items from the Internal list.  If one of these modifying operations is called, and RaiseListChangedEvents is set to false, I could set this flag, and at other points check the flag and rebuild the flattened list if needed.  I'm not sure if that's the best way to handle this (and I'm not sure keeping to lists in sync was the best way to get either). 

Am I going about this in the best way possible?

Thanks
Andy

xal replied on Friday, October 12, 2007

Do you _really_ need to keep the flat list in sync with the bo? I assume you're not going to be displaying both things at the same time, so why not create it on demand? it seems like it would be fast enough doing it this way, since you are talking about invoices which generally don't have that many items.

Another possibility (since I hear you use infragistics stuff) is to use their tree view which works like a grid essentially. That way you don't need to flatten the hierarchy and you save yourself from that step.

Andrés

ajj3085 replied on Monday, October 15, 2007

Well, it sort of is created on demand.  I rebuild the whole flattened list when needed.. its just that now I have a situation where it the rebuild doesn't happen as it should..

Some of our invoices can have 30 items... and that's not counting "sub" items.

In this case, using the hierachry capability of the grid is out of the question; I did specifically ask about it, since there are other places where I have implemented that.  The answer for this use of the grid was a very firm No.

ajj3085 replied on Monday, October 15, 2007

Well I did some quick reworking; basically, I now set a flag if the list is modified in anyway and RaiseListChangeEvents is off.  The underlying list also always raises events.

Anything that queries the list will rebuild the flattened list if the flag is set; also, if RaiseEvents is true, I don't rebuild the flattened list if the change type is simply ItemChanged (anything else would require a rebuild).

I now set both the binding source and the list's RaiseLCE to false before inserting even a single item and turn it back on and ResetBindings after.  Performance is now as quick as it would be with a standard list.