I'm trying to optimize code that displays a grid from a database query. Right now (vastly simplified), we:
This works, vastly reduces the data transmitted, and helps the grid understand that these are "compatible" layouts. But it is in practice quite inefficient (for example, filtering can noticeably lag). What I'd prefer is for the grid to internally work with columns that actually exist; i.e. to skip step 4.
What I'd like to move towards is something like:
I don't really mind step 5, but it seems a little inefficient. I could also simplify step 2, perhaps by specifying PropertyCategories.Bands.
But the bigger issue I run into right now is that the grid "forgets" some of the display layout along the way (such as sorted columns and groupby columns). Is there a way to "merge" the current grid's state to a new data source?
Is there something much easier that I'm missing to accomplish this? :)
Sören Kuklau said:But the bigger issue I run into right now is that the grid "forgets" some of the display layout along the way (such as sorted columns and groupby columns). Is there a way to "merge" the current grid's state to a new data source?
Huh, never mind that part. It was the fact that we were disposing the old data source that caused the display layout to be reset. If I simply save the layout to a byte, then load it again from the same byte after the data source has been exchanged, the settings do get preserved (even if the new data source has additional columns).
Still: are there more efficient/nicer ways of doing these?
.Where(c => !c.Hidden || c.IsGroupByColumn)
.Select(c => c.Key.ToLower())
I have been investigating into your queries in this case, and I believe the route that you are currently going with your most recent update to this thread is the best route. Regarding the more efficient ways of doing the parts you have asked about, I will address those below:
1. Getting the layout’s columns: In order to get a layout’s columns from a previously saved layout, I would recommend continuing with what you are currently doing. The only other alternative I can think of that might prove to be more performant (but almost certainly more complicated) would be to parse the XML file that you are loading and read the UltraGridColumn tags to find the ones that are hidden.
2. Reapplying the layout after old data source is replaced: The generation of the UltraGridLayout is determined by the bound data source, hence the reason that the InitializeLayout event of the grid is fired when a DataSource is applied to the grid. As long as the column names/keys correspond to the previous layout, you should be able to reapply the layout after assigning the new data source and it should be respected, though.
Please let me know if you have any other questions or concerns on this matter.
alright, thanks. That confirms I'm on the right track for both aspects. :)