I have solved this issue for the most part, at least for now. I replaced the recursive method that drilled down to every row to set the row activation; instead, it now  sets column activation within each band. This also improved performnce. Secondly, on the ExpandAll, I only expand the visible rows which also entailed adding the AfterRowRegionScroll event to expand any row scrolling into view if necessary

Mike,

Thank you for your response. We had an inkling as to what you would say, but we just needed your affirmation.  Thanks again.

Ron 

Hi Ron,

Sorry for not responding sooner. For some reason, I never got any e-mail notification about posts.

I just took a quick look at your sample. If I am reading this right, it's no great mystery why you are getting that exception. You are trying to create a huge amount of bands in the grid.

In my experience the BindingManager in DotNet tends to slow down at around 5 Bands, and it becomes totally unusable with 10. It depends on the data and the hierarchical structure, of course, but having 800 bands at the 4th level of the grid is just not feasible.

Creating a separate DataTable to allow you to have variable columns at the fourth level of the grid is not going to be possible in anything other than a very small number of rows.

You might be able to do what you want using UltraWinTree instead of UltraWinGrid, since the WinTree allows you to bind to a Non-homogenous data source and defined the ColumnSets on each individual node, if that's what you want.

But I still can't imagine that any user would ever be able to work effectively with so much data in the UI. It would be nearly impossible to even find what they were looking for. Perhaps you could give your users some way to retrieve this data in chunks with some kind of query interface.

I've been waiting for some sort of reply. Could someone please acknowledge that the example was received and tried?

Ron

Has anyony had a chance to run the previously sent sample project attachment?   

Ron