View Issue Details

IDProjectCategoryView StatusLast Update
0031518LazarusLCLpublic2017-05-27 15:12
Reporteraccorp Assigned ToOndrej Pokorny  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.7 (SVN) 
Summary0031518: TStringGrid resize problem
DescriptionTStringGrid rows does not fill available space on control resize.
Steps To ReproduceStart test application, resize window on the bottom.
TagsNo tags attached.
Fixed in Revision54381, 54732, 54733
LazTarget-
WidgetsetGTK 2
Attached Files

Activities

accorp

2017-03-10 13:05

reporter  

bug-31518.tar.gz (1,553 bytes)

Ondrej Pokorny

2017-03-10 13:14

developer   ~0098797

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?

accorp

2017-03-10 13:17

reporter  

resising.gif (144,129 bytes)   
resising.gif (144,129 bytes)   

Ondrej Pokorny

2017-03-10 13:18

developer   ~0098798

I don't have such a problem on Windows. What is your OS and WidgetSet?

accorp

2017-03-10 13:18

reporter   ~0098799

Caused by removing DoOnChangeBounds.
Should I remake patch from 0021918 ?

accorp

2017-03-10 13:18

reporter   ~0098800

Xubuntu, GTK2

Ondrej Pokorny

2017-03-10 13:34

developer   ~0098801

> 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.

accorp

2017-03-10 13:36

reporter   ~0098802

Last edited: 2017-03-10 13:37

View 2 revisions

DoOnChangeBounds was wrong indeed. But I solved this issue restoring it with call to VisualChange.

Ondrej Pokorny

2017-03-10 13:41

developer   ~0098803

This issue is Gtk2-specific. Win32 and Qt work fine.

accorp

2017-03-10 13:51

reporter   ~0098804

Grid is actually scrolling but not repainting and scrollbar moves to wrong position.

Ondrej Pokorny

2017-03-10 13:53

developer   ~0098805

Yep, VisualChange helped. Gtk2 seems to postpone the paint message until resizing is finished.

Ondrej Pokorny

2017-04-25 12:20

developer   ~0099913

Last edited: 2017-04-25 12:21

View 3 revisions

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).

Ondrej Pokorny

2017-04-25 12:35

developer   ~0099914

Last edited: 2017-04-25 12:41

View 2 revisions

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 :)

wp

2017-04-25 13:22

developer   ~0099916

Looks good (Win 10). Thank you.

Issue History

Date Modified Username Field Change
2017-03-10 13:04 accorp New Issue
2017-03-10 13:05 accorp File Added: bug-31518.tar.gz
2017-03-10 13:14 Ondrej Pokorny Note Added: 0098797
2017-03-10 13:17 accorp File Added: resising.gif
2017-03-10 13:18 Ondrej Pokorny Note Added: 0098798
2017-03-10 13:18 accorp Note Added: 0098799
2017-03-10 13:18 accorp Note Added: 0098800
2017-03-10 13:34 Ondrej Pokorny Note Added: 0098801
2017-03-10 13:34 Ondrej Pokorny Assigned To => Ondrej Pokorny
2017-03-10 13:34 Ondrej Pokorny Status new => assigned
2017-03-10 13:36 accorp Note Added: 0098802
2017-03-10 13:37 accorp Note Edited: 0098802 View Revisions
2017-03-10 13:41 Ondrej Pokorny LazTarget => -
2017-03-10 13:41 Ondrej Pokorny Widgetset => GTK 2
2017-03-10 13:41 Ondrej Pokorny Note Added: 0098803
2017-03-10 13:51 accorp Note Added: 0098804
2017-03-10 13:53 Ondrej Pokorny Fixed in Revision => 54381
2017-03-10 13:53 Ondrej Pokorny Note Added: 0098805
2017-03-10 13:53 Ondrej Pokorny Status assigned => resolved
2017-03-10 13:53 Ondrej Pokorny Resolution open => fixed
2017-03-10 13:59 accorp Status resolved => closed
2017-04-25 12:20 Ondrej Pokorny Note Added: 0099913
2017-04-25 12:20 Ondrej Pokorny Status closed => assigned
2017-04-25 12:20 Ondrej Pokorny Resolution fixed => reopened
2017-04-25 12:21 Ondrej Pokorny Note Edited: 0099913 View Revisions
2017-04-25 12:21 Ondrej Pokorny Note Edited: 0099913 View Revisions
2017-04-25 12:35 Ondrej Pokorny Fixed in Revision 54381 => 54381, 54732, 54733
2017-04-25 12:35 Ondrej Pokorny Note Added: 0099914
2017-04-25 12:35 Ondrej Pokorny Status assigned => resolved
2017-04-25 12:35 Ondrej Pokorny Resolution reopened => fixed
2017-04-25 12:41 Ondrej Pokorny Note Edited: 0099914 View Revisions
2017-04-25 13:22 wp Note Added: 0099916
2017-05-27 15:12 accorp Status resolved => closed