|
|
|
|
|
Please explain the bug. I don't see the problem. Do you mean that the 99-row is not fully visible when the form is opened? |
|
|
resising.gif (144,129 bytes) |
|
|
I don't have such a problem on Windows. What is your OS and WidgetSet? |
|
|
Caused by removing DoOnChangeBounds. Should I remake patch from 0021918 ? |
|
|
Xubuntu, GTK2 |
|
|
> Caused by removing DoOnChangeBounds. > Should I remake patch from 0021918 ? No. The calculation in DoOnChangeBounds was wrong and had to be removed. I'll check why scrolling is fine on Windows but fails on Linux/Gtk2. Probably some missing message from the LCL. |
|
|
DoOnChangeBounds was wrong indeed. But I solved this issue restoring it with call to VisualChange. |
|
|
This issue is Gtk2-specific. Win32 and Qt work fine. |
|
|
Grid is actually scrolling but not repainting and scrollbar moves to wrong position. |
|
|
Yep, VisualChange helped. Gtk2 seems to postpone the paint message until resizing is finished. |
|
|
Regression (wp) - win32: Since r54381, the grids are behaving differently upon resizing. So far, they could be resized smoothly. But now there is a "stopper" when the size just matches the minimum size given by the row and column count before scrollbars would appear/disappear. This is most prominent in designmode of non-aligned, non-anchored grids. But it happens also at runtime, if grid size is changed in steps by button clicks (a rare use-case, I agree...) I don't know if I like this feature or if I don't... On the one hand, I remember how often I fiddled around to get the grid size right such that no scrollbars appear. But on the other hand, this feature may drive a user crazy if he intentionally wants to design a grid to a smaller width or height. For a test, create a new form and add a TStringGrid. On my system, the grid is smaller than the space occupied by columns and rows. Using the mouse increase the width of the grid slowly. Notice that the width stops increasing when the horizontal scrollbar disappears. Same with the height - with the exception that the vertical scrollbar does not disappear. Using the keyboard (SHIFT + LEFT/RIGHT ARROW) does not produce any change any more at this point. The user will be very confused before he notices that he may drag the mouse very quickly - then suddenly the "lock" releases and the size can grow again. The same also when you decrease the widht/height now starting at a too-large state. Again, if you do this slowly the size gets locked at the moment the scrollbars would appear. But note there is still some white space between the last column/the last row and the outer grid border. This is particularly annoying since there is no way to smoothly tune the size any more. I don't understand why there is a difference between the cases "increasing from the too-small size" and "decreasing from the too-large side". So, basically, I think this is a useful feature. But it is implemented in an inconsistent way. The grid should look the same in the locked state independently of the size is increased or decreased. And I think it should be made optional, and it should not be the default. A suitable user-interface, in my eyes, would be to activate the locking feature only when the ALT (or some other key) is pressed while dragging the size boxes (I chose ALT here because CTRL and SHIFT are already reserved for positioning and resizing controls using the keyboard). |
|
|
It's a bug and not a feature. At least I didn't want to make this happen :) I assume there are some almost-endless repaint loops or similar that don't let the grid resize. Please retest both of you :) |
|
|
Looks good (Win 10). Thank you. |
- Anonymous
