View Issue Details

IDProjectCategoryView StatusLast Update
0016458LazarusWidgetsetpublic2019-04-22 19:33
ReporterMartin FriebeAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.29 (SVN)Product Build 
Target VersionFixed in Version1.7 (SVN) 
Summary0016458: GTK2 = SetScrollInfo makes hidden scrollbar visible (differs from w32 widgetset)
DescriptionIf a scrollbar was hidden via ShowScrollBar, it can still be positioned by SetScrollInfo.

In fact is must be in order to allow the mousewheel to work (the mousewheel uses ThumbTrack, and requires the previous position to be set, so it can send the new pos)
[see http://bugs.freepascal.org/view.php?id=15765 ]

Under GTK using SetScrollInfo will un-hide the scrollbar. under Windows this is not the case.
Additional InformationSee SynEdit.UpdateScrollbars line 4316
    SetScrollInfo(Handle, SB_VERT, ScrollInfo, True);
    {$IFnDEF SynScrollBarWorkaround}
    ShowScrollBar(Handle, SB_Vert, sfVertScrollbarVisible in fStateFlags);
    {$ENDIF}

compile with -dSynScrollBarWorkaround

- Create new app
- drop synedit on it
- set Scrollbars to ssNone
- add some lines of text (more lines, than fit the visible area, so it can be scrolled)
- scroll (mouse wheel)
 => scrollbars will appear
TagsNo tags attached.
Fixed in Revision
LazTarget-
WidgetsetGTK 2
Attached Files

Relationships

related to 0017070 resolvedZeljan Rikalo Form Vertical or Horizontal ScrollBar disappears 

Activities

Zeljan Rikalo

2010-05-20 11:06

developer   ~0037812

So what should be normal behaviour of gtk2 in this case ?
Just move pos/change range whatever, and don't change visibility ?

Martin Friebe

2010-10-06 21:45

manager   ~0041554

Last edited: 2010-10-06 21:47

Ok, done some tests:

SetScrollInfo(Handle : HWND; SBStyle : Integer; ScrollInfo: TScrollInfo; bRedraw : Boolean): Integer;

About the last param "redraw"

** Under GTK2, redraw currently causes:
- the scrollbar to be show (if there were hidden before)
- gtk_widget_queue_draw(PGTKWidget(Scroll)) if there were already visible (and also gtk_adjustment_changed)

Both effectively:
- make them visible and invalidate them (redraw at next process mesages)

** Under Windows:
If the scrollbar is not visible, it is kept invisible

"redraw=True" causes an immediate redraw (even without processMessages)
This code causes the scrollbar to be redrawn each time (if it was already visible)
   for i := 1 to 20 do begin
      ScrollInfo.nPos := i*10;
      SetScrollInfo(Handle, SB_HORZ, ScrollInfo, TRUE);
      sleep(500);
    end;

"redraw=False" simply updates the scrollbar, but doesn't even invalidate it. So the scrollbar isn't even redrawn at the next ProcessMessages (rather odd behaviour, asking myself if MS indented that).
(The scrollbar is only redrawn if it gets invalidated by anything else.)


----
If we intend to follow the window standard, then a none visible scrollbar should be kept none visible.

Not sure about the rest, but that would be a different bug anyway

-- Edit:
from http://msdn.microsoft.com/en-us/library/bb787595%28VS.85%29.aspx

fRedraw [in] BOOL Specifies whether the scroll bar is redrawn to reflect the changes to the scroll bar. If this parameter is TRUE, the scroll bar is redrawn, otherwise, it is not redrawn.

So MS doesn't specify that the effect of redraw is to be immediate.

Zeljan Rikalo

2010-10-10 21:08

developer   ~0041708

hm..this looks much deeper problem than it is.
bRedraw doesn't trigger show (queue_draw inside etc) of scrollbars (but it can of course like you mentioned before).

Just put after "if bRedraw" and GTK_WIDGET_VISIBLE(PGtkWidget(Scroll)) and you'll see that visible scrollbar comes here later.

Zeljan Rikalo

2016-04-10 21:11

developer   ~0091918

@Martin, just tested with Lazarus 1.7 r52158M FPC 2.6.4 x86_64-linux-gtk 2 and cannot reproduce this issue with steps you provided. Can you confirm that issue is fixed in the meantime or there's some gtk2 workaround in synedit ?

Martin Friebe

2016-04-28 19:55

manager   ~0092279

Did you test with -dSynScrollBarWorkaround ?

But yes, I tested under my old Fedora 13 (where I originally was able to see the bug). It works fine now.

Martin Friebe

2016-04-28 19:56

manager   ~0092280

fixed in the meantime

Issue History

Date Modified Username Field Change
2010-05-12 20:13 Martin Friebe New Issue
2010-05-12 20:13 Martin Friebe LazTarget => -
2010-05-12 20:13 Martin Friebe Widgetset => GTK 2
2010-05-20 11:06 Zeljan Rikalo Note Added: 0037812
2010-05-20 11:06 Zeljan Rikalo Status new => feedback
2010-10-06 21:45 Martin Friebe Note Added: 0041554
2010-10-06 21:47 Martin Friebe Note Edited: 0041554
2010-10-10 21:08 Zeljan Rikalo Note Added: 0041708
2010-11-26 10:17 Vincent Snijders Status feedback => acknowledged
2014-10-07 20:18 Juha Manninen Relationship added related to 0017070
2016-04-10 21:11 Zeljan Rikalo Note Added: 0091918
2016-04-10 21:11 Zeljan Rikalo Status acknowledged => feedback
2016-04-28 19:55 Martin Friebe Note Added: 0092279
2016-04-28 19:55 Martin Friebe Status feedback => new
2016-04-28 19:56 Martin Friebe Note Added: 0092280
2016-04-28 19:56 Martin Friebe Status new => resolved
2016-04-28 19:56 Martin Friebe Fixed in Version => 1.7 (SVN)
2016-04-28 19:56 Martin Friebe Resolution open => fixed
2016-04-28 19:56 Martin Friebe Assigned To => Martin Friebe
2019-04-22 19:33 Martin Friebe Status resolved => closed