Welcome Guest! To enable all features please Login or Register.



Go to last post Go to first unread
#1 Posted : Sunday, February 7, 2016 3:05:55 PM(UTC)

Rank: Member

Groups: Registered
Joined: 10/22/2015(UTC)
Posts: 24
Location: Alsace, France

Thanks: 6 times
Was thanked: 1 time(s) in 1 post(s)
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.

Edited by moderator Wednesday, March 22, 2017 2:06:56 PM(UTC)  | Reason: Igor/10Tec added implementation status

#2 Posted : Monday, February 8, 2016 8:15:39 AM(UTC)

Rank: Administration

Groups: Administrators, Forum Moderator
Joined: 1/17/2011(UTC)
Posts: 843

Thanks: 11 times
Was thanked: 111 time(s) in 111 post(s)
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":

iGrid ActiveX Stroing Objects in Tag Properties.png

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.
thanks 1 user thanked Igor/10Tec for this useful post.
jauno on 2/9/2016(UTC)
#3 Posted : Wednesday, March 22, 2017 2:06:31 PM(UTC)

Rank: Administration

Groups: Administrators, Forum Moderator
Joined: 1/17/2011(UTC)
Posts: 843

Thanks: 11 times
Was thanked: 111 time(s) in 111 post(s)
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.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.