Marc Weustink wrote:
Luiz Americo Pereira Camara wrote:
While debugging scrolling bugs in LCL i found that ClientToScreen
acts differently according to the widget set.
These are the behaviors:
1) The returned value is related to the actual position, i.e., it
does not consider the scroll offset. If you pass Point(0,0) the value
will be the same regardless of the scroll position. (Gtk1)
2) The returned value is related to the virtual position, i.e, it
takes into account the scroll offset. If you pass Point(0, 0) the
value changes inversely to scrollbar position. (Gtk2) 3) The
returned value is related to the virtual position, i.e, it takes into
account the scroll offset. If you pass Point(0, 0) the value changes
the same amount of scrollbar position. (Win32)
4) Nothing. Qt has no visible scrollbars so...
Notes:
Delphi does the same as (1)/Gtk1
Not really, internally Delphi does it like 2. All controls are moved.
I'm not referring to position of controls after scrolling. I'm referring
to ClientToScreen return results. Say you query the ClientToScreen with
0,0 will return value x, y. Now scroll vertically amount n. Under Delphi
the returned value will still be x, y and not x, y-n that is the virtual
position. The example shows this clearly. Move the window to position
0,0. Get the ClientToScreen result of 0,0 = 0,0. Now scroll vertically
10 (Notice that part of the client area is offscreen). Get again the
value of 0,0. You will get
Win32: 0,10
Gtk1: 0,0
Gtk2: 0, -10
Delphi: 0,0
The patch makes win32 behaves like Gtk2 each makes more sense.
(3) is clearly buggy.
Between (1) and (2) is a design decision.
We started like delphi, move controls and report corrected values when
asked. However this aproach is very inefficient on all widgetsets
except win32. So the new approach is that controls stay at their
position and only the "virtual parent" gets an offset.
This means that the top/left of a control on a say scrollbox are
allways the same, an offset to the "virtual parent" top/left.
See above.
So now ClientToScreen.
The top/left of a scrolled control needs to get a scrolled offset, so
that is reflects the "real" position relative to the "real" parent of
the control.
The behavior described here is generic to any point, not control
position related.
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
