Currently, the CellIndent* properties are declared "As Byte", which limits the possible indentation to 255. We currently have a case where we just barely come out with more, namely 300. Is there a reason for using Byte as the type here or could that be increased to Integer?

It's a rare case we are running into but since the data we want to show is created by the customer, we can't stop him from creating many levels, which we represent by indenting. We could reduce the amout of indenting for each level to make it fit now, but nothing prevents the customer from adding another level or two next time, which repeats the problem. Besides, on a 1920x1080 display, there is lots of room for indents.

Regards,
Oliver

The CellIndent* properties have the Byte type by design, and we will not change this in the future. The fact is that the iGrid cell has these 4 (FOUR) parameters which can be set INDIVIDUALLY for EVERY cell. If we used Integer or even Long for these values, we would definitely lose a lot of memory for big grids as in 99.99% of cases the values of these parameters are not greater than 10.

To tell you the truth, you are the first who requested to increase the room for these properties. Looking at your question, I can suppose that iGrid has a better way to implement row hierarchy so you may not need to use CellIndentLeft for this at all. What about to use row levels for that (see the RowLevel property)? This will also allow you to implement interactive tree structure for your data with the ability to collapse/expand children rows.

The CellIndent* properties have the Byte type by design, and we will not change this in the future. The fact is that the iGrid cell has these 4 (FOUR) parameters which can be set INDIVIDUALLY for EVERY cell. If we used Integer or even Long for these values, we would definitely lose a lot of memory for big grids as in 99.99% of cases the values of these parameters are not greater than 10.

To tell you the truth, you are the first who requested to increase the room for these properties. Looking at your question, I can suppose that iGrid has a better way to implement row hierarchy so you may not need to use CellIndentLeft for this at all. What about to use row levels for that (see the RowLevel property)? This will also allow you to implement interactive tree structure for your data with the ability to collapse/expand children rows.

We already do use the rowlevels for the "primary" column. But the Grid has a lot of columns and there is sort of a "comparison" column to the right that I wanted to indent the same as the tree-column.

You are right about the 99% in our case, too. The case where this deep indentation is needed is an edge case with sort of misused/bad data. I just wanted to ask as it seemed like an artificial limit to me. I can understand the memory aspect however, even though current machines have lots of RAM, we don't need to waste it. (MSAccess is already quite the memory hog)

I do have a workaround for our scenario, so it's ok to close this topic.