We have a few iGrids in our Application now and the application is distibuted over various machines.
Some columns of the Grid are created with the lMaxWidth set, to prevent these columns to expand to very large sizes because of the free text fields contained in them.
The general approach in our App is to fill the grid from the DB, then apply the AutoWidthCol method to all columns to make them appear as big as they need to be.

Now, we can observe the following behaviour:
On ALL machines, when using the AutoWidthCol method, the MaxWidth is used and the column appears as it is specified.
On SOME machines, the USER can then drag the separator and make the column bigger than the MaxWidth. This is clearly not the documented behaviour. On the rest of the machines, the user can not do that.

Did you ever come accross that effect? Are you aware of any dependencies on something else that might cause this?

To make my intention clear: I actually LIKE the effect that the MaxWidth is only used for the AutoWidthCol, enabling me to specify a sane layout default without removing the ability of the User to widen the column if he likes to do so.

Still, I can't rely on that effect, if it varies between machines.
(So far, it happen son all WinXP machines, but we also have TWO Win7 machines that hav this behaviour)

Regards,
Oliver

We have never seen this strange effect before, but as for dependencies, we have one idea.

iGrid's header is based on the MS Header control, which is a native Windows component and comes with the client OS. Different versions of Windows provide your users with different versions of the Header control, and thus the behavior may change (though it should not happen).

The functionality can also depend on some factors, such as visual styles. They can be enabled/disabled in the whole OS, or in a particular app or even inside just one grid.

What I suggest to do is to try to figure out when the iGrid header does not work as expected looking at the points I've just described. If we will be able to recreate the environment in which this behavior is reproduced, that could help us a lot.

****

Another idea that can help. When the user is trying to resize a column, the corresponding internal code of iGrid checks whether the user can do that and restricts the area in which the cursor can be moved if ColMaxWidth is specified. When this code works, the ColWidthStartChange event should be also raised as a part of this code snippet. Check whether this event is triggered so we will know whether this logic works at all.

Check also the ColAllowSizing property which can affect this part of code too.

iGrid's header is based on the MS Header control, which is a native Windows component and comes with the client OS. Different versions of Windows provide your users with different versions of the Header control, and thus the behavior may change (though it should not happen).

The functionality can also depend on some factors, such as visual styles. They can be enabled/disabled in the whole OS, or in a particular app or even inside just one grid.

What I suggest to do is to try to figure out when the iGrid header does not work as expected looking at the points I've just described. If we will be able to recreate the environment in which this behavior is reproduced, that could help us a lot.

I tried to compare the referenced library versions using the Dependency Walker, but the libs (most importnatly the common controls) are the same on most computer, even though they behave differently. I also verfied the settings for visual styles in the OS and they were also the same. No luck so far.

Another idea that can help. When the user is trying to resize a column, the corresponding internal code of iGrid checks whether the user can do that and restricts the area in which the cursor can be moved if ColMaxWidth is specified. When this code works, the ColWidthStartChange event should be also raised as a part of this code snippet. Check whether this event is triggered so we will know whether this logic works at all.

Check also the ColAllowSizing property which can affect this part of code too.

I did try that, too and the code is triggered fine with the lWidth reported correctly, over and under the max. I set when creating the columns. I toggled the .ColAllowSizing property as well, but that works as expected. Toggling the .UseXPStyles also has no effect.

Another thing I noticed is that the color of the column headers when the mouse moves over it is slightly different on computers that show the strange behaviour, too. It's not too much, but noticeable when you know what you look for. This points to a problem with themeing or such, as you already mentioned.

I will try to compare more settings and configurations of the two machines to find out more.

Regards,
Oliver

Just to let you know, I compared all the versions of the dlls that the ocx draws in (via DependencyWalker) and there is NO relevant difference, except some filedates.

Theme configurations are the same, too, so i'm lost about why the app behaves that differently on these machines.

Regards,
Oliver