For database programming it is indispensable to keep unique IDs for each cell for a probably non-unique cellvalue to store the data back to DB.
We already have the possibility to define coltags, colkeys, rowtags, rowkeys to identify selected rows/cols by the user.
But what if those properties are already in use?
We can manage the problem in VB to synchronize every cell with an 2-dimensional array to store the Db ID in it.
This is very laborious in case of adding/deleting cells or rows.
A way out of this could be to offer the possibility to store an extra cellkey/celltag property for each cell of the grid.
CellTag/CellKey could be a usefull implementation of iGrid for database programmers.

In iGrid, we try to minimize the amount of used memory everywhere where it is possible. This concerns the internal cell data. For instance, the Boolean CellSelectable property is stored as 1 bit (!) instead of using of a real Boolean field that takes whole 2 bytes in memory. You can open the iGrid source code and look at the definition of the tGridCell structure that represents the properties of an iGrid cell. You'll see that many Boolean properties are stored as packed bits, and bitwise operations are used to work with them.

When we designed iGrid, we decided not to implement an equivalent of the CellItemData property for every cell you can find in other grid controls like the vbAccelerator SGrid control. The reason was only one - to save memory. This property is used enough rarely, and for huge girds we would lose much memory. For instance, if we have a grid with 100'000 rows and 20 columns, we waste 8Mb of RAM if we do not use Long CellItemData for every cell. Add to this other non-used properties, such as CellBackColor or CellFont, and you get much more unused bytes. BTW, iGrid cell fonts are stored not as objects but as numeric indices pointing to another internal table of unique fonts. The same technique is used for format strings, etc.

The total savings are very high if we take into account indexed format strings and cell font objects, packed Boolean properties stored as bits, etc. In my estimation, we can save 100 bytes per cell for an "average" grid that uses a half of available cell properties. For a grid like mentioned above, we save 200Mb of RAM. Not bad, right? Especially if we take into account the fact that if we did not do that, the grid would use much more memory and swapping to the Windows page file would occur.

Well, there are some tricks you can use to store additional data for your cells inside iGrid. One of them is described in the iGrid help in the topic titled "Storing Objects in Tag Properties":



Another idea is the following. If you do not use icons in your grid, you can use the CellIcon and CellExtraIcon properties to store Integer extra data for your cells. The trick is that those values aren't used by iGrid in the cell drawing routine if the cell (grid) does not have an associated image list. You can even sort iGrid by these data using the built-in sort types igSortByIcon or igSortByExtraIcon!

In any case, I keep this suggestion in mind. Perhaps, I'll "open" some internal cell properties for the purpose of storing extra cell data like we discussed it with you in this thread:

How to retrieve item values in combos with style igCellTextCombo 

Note that if you need it solely for combo box cells, there is no need to implement something new as we already have all what we need inside iGrid. We just need to "open" it for public usage.

iGrid 6.5 released today implements the CellExtraData property for this purpose. It allows you to store any Long value associated with a cell. The grid can be sorted by these extra values using the new igSortByExtraData sort type.

P.S. I think having this property of the Long type instead of Variant is a good balance - we occupy only 4 extra bytes in memory per cell.