Our application running under VisualStudio C# and WinGrid Version 8.1.20081.2013 gets the out of memory exception if there are several hundred rows selected that are recursed through because if several levels of descendants each to set row activation and/or ExpandAll. Is there any thing that can be done to prevent this?
Ron
Hi Ron,
Without seeing what your code is doing or a sample that demonstrates the exception, I cannot guess why it's occurring or how to avoid it.
Can you post a sample?
I've attached a simplifed sample application. Run the app and click on either the ExpandAll button or the SetActivation button and see if you get the OutOfMemoryException .
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.
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?
Has anyony had a chance to run the previously sent sample project attachment?