Infralution Support

[MHB]

Yet another issue to do with dynamic sizing and the order of determining what is visible...

When I have a column with AutoSizePolicy set to AutoSize, there seems to be a problem getting the right column width when collapsing rows. Specifically, if there is a row with a wide column value below the visible columns, and it becomes visible by collapsing a row above it, the column width computation does not take this row into account, so the column is not expanded as it should be.

[Infralution]

A sample project illustrating this issue would be really helpful - you can email it to support@infralution.com
_________________
Infralution Support

[Infralution]

Thanks for the sample project. It is a fairly subtle problem. It only occurs if AutoFitHeight is set for the row and the automatically calculated height is less than the default RowHeight for the tree. In this case the tree does not correctly calculate the number of rows that could be displayed and so may not adjust the automatic column width for rows at the bottom of the control.

The workaround for this is to increase the MinRowHeight to be equal to RowHeight so that AutoFitHeight row height will be the same as non auto fit rows, or you can reduce the default RowHeight so it is equal or less than the auto calculated row height (for your sample this is 14)

We should have a fix for this out soon.
_________________
Infralution Support

[MHB]

Indeed, it is a rather obscure bug. As I commented in the mail, it took many attempts to get it to display in a sample project. And you're right, it does go away if you increase MinRowHeight. But I think this is just a coincidence, partly because it also goes away if you slightly adjust other parameters, and partly because I already increased MinRowHeight to 18 in my application, due to the problem with displaying an editor inside a cell, and the current problem still appears once in a while.

As I wrote in my first post in this thread, the circumstances revealing the bug are usually different from those in the sample project, so I simply hope it really is the same bug that can be exposed in different ways...

I've seen the problem several times, and when it appears, it's consistently replicatable under those particular circumstances. I have a hard time spotting the common pattern though, and hence had trouble exposing the problem in a sample project.

[MHB]

I can see that in 2.3.0 you managed to fix the error exposed by my sample project! However, I'm still seeing the original problem, so I'm afraid they were unrelated

[Infralution]

Unfortunately we are going to need a sample project to resolve this - so see what you can do.
_________________
Infralution Support

[Infralution]

Thanks for the sample projects - I think we may have finally got to the bottom of this one. Check out the latest release (2.3.1) and let us know if there are still any issues.
_________________
Infralution Support

[MHB]

I think it worked! At least the problem now disappeared in the simplest test I've been using.
Cheers