In the Virtual Grid Mode that you are discussing, are you talking about the case when we implement the QueryCellInfo?
According to the docs, the data retrieved from QueryCellInfo is cached by the grid. From a quick look, it seems that the grid only caches the data for the visible, on-screen, rows/columns. When the grid is scrolled to show a different set of rows/columns it appears that QueryCellInfo then, and only then, asks for the data ( and caches it ). In summary, it appears that QueryCellInfo only gets called for visible, on-screen, cells and that the cached data is only for painting what is seen. Correct?
I know that we'd call ResetVolatileData to get the screen to update, forcing new calls to QueryCellInfo. Is there a way to target just 1 row, i.e. to reset a subset? I'm thinking about avoiding a full repaint/redraw. ( Maybe the grid does a diff and keeps the painting to a minimum?? )
Also: When doing a virtual grid with QueryCellInfo and ResetVolatileData, I ran into the case where I wanted to change the DefaultRowHeight. I happened to have 300,000+ rows in my grid, and I noticed ( by using the debugger to step into the grid code ) that there was a collection of RowHeights that was being iterated. It seemed to be a bit heavy. So, I was also wondering if there is a recommended way to take over the management of RowHeights and make the grid assume that all rows are exactly the same height, so as to avoid iterating over rows.
Sorry about clumping all these questions together.
if I have, say, 100,000 rows of data to display, the grid still internally creates 100,000 rows in the grid, along with that many internal data structures like collections for hidden rows, row heights, etc. Is this correct?
No, The virtual grid does not hold any data. All data is supplied to the grid from an external data source on demand. When the grid needs a particular cell, say to draw it, it asks the external data source for that value. Since no data is actually loaded into the grid, there is virtually no limit imposed by Essential Grid on the number of rows and columns you can have.
The Rows.Hidden is actually a dictionary. When you hide a row explictly using Model.Rows.Hidden property, an entry is created in the dictionary, and when you make a row visible, this entry is removed from the dictionary. When you call Hidden.SetRange, the grid will only allocate storage for the entries that you specify. This means that if you have 5,000,000, and hide every other one with this technique, then there will be 2.5M entries. However, in such a situation, you could implement such a grid virtually using QueryRowHeight with no memory allocationn. I guess my commnet was to suggest if you use a virtual grid, special knowledge of what you are trying to hide may allow you to do something more economical than the standard implementation that has to work for any case.
Another consideration for the short term is that grids with a large number of hidden rows can have poor scrolling performannce. If you manage your own dictionary, you can actually avoid this scrolling performance penalty by treating all rows as if they were contiguous no matter where they are in your external data source. This would mean that you would have row map allocated, but it would enhanced scrolling performance for the time being.