TControl.ScrolledClientRect offsets *all* fields in the TRect by the scroll offsets. This is *incorrect*, when the TRect is initialized to ClientRect, where the second set of coordinates is the Width and Heigth, not the BottomRight corner of the area. Obviously Width and Height are insensitive to scrolling!

The ambiguous use of TRect, with either BottomRight or WidthHeight in the second TPoint, often leads to misunderstandings and flawed code (as above). It were helpful when type alias would be introduced and used, or when the argument names would indicate the current content of an TRect.

E.g. in the EasyDockManager I use XYWH or TLBR for the argument names, to clarify the content of the passed TRect.

DoDi

Hans-Peter Diettrich wrote

The ambiguous use of TRect, with either BottomRight or WidthHeight in the second TPoint, often leads to misunderstandings and flawed code (as above). It were helpful when type alias would be introduced and used, or when the argument names would indicate the current content of an TRect.

Where exactly is TRect used to hold the Width and Height? File and Line.

Hans-Peter Diettrich wrote

TControl.GetClientRect (controls.inc 1525..)

wow, what a nasty thing =D I was using it wrongly myself.

Unfortunately it is Delphi-compatible:

http://docwiki.embarcadero.com/VCL/en/Controls.TControl.ClientRect

?

Hans-Peter Diettrich hat am 7. Oktober 2011 um 11:52 geschrieben:

They both return a Left,Top,Right,Bottom.
ClientRect Left,Top is 0,0, so Right=ClientWidth and Bottom=ClientHeight.? ?

?

A similar problem exists with mouse coordinates, which can be either screen or client coords.?

?
Mattias?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111007/97960a3f/attachment.html>

TControl.GetClientRect
(controls.inc 1525..)

BoundsRect and ClientRect contain different information, despite the similar name and type.

A similar problem exists with mouse coordinates, which can be either screen or client coords.

DoDi

?

Hans-Peter Diettrich hat am 7. Oktober 2011 um 13:18 geschrieben:

I'm not sure what you mean with "inner borders".?
The ClientRect excludes scrollbars and is relative to the left, top of the visible client area (so Left,Top are almost always 0,0). So for almost all uses it is simply the size of the visible area, where a control can paint and gets mouse events.?
?

?

But I agree that client areas *could* be described by TopLeft and BottomRight points, when the implementation is consistent. AFAIR there exist (derived) controls with a client origin (0,0)...?

That is possible, but I don't know any. ?
?
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111007/347d8aee/attachment.html>

?

Hans-Peter Diettrich hat am 7. Oktober 2011 um 13:33 geschrieben:

Yes.
During Creation and Destruction they may have less than two.? They have a Visible property.?
?

If so, a check of only one scrollbar would be sufficient, otherwise every scrollbar must be checked individually!?

Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111007/df1cef91/attachment.html>

Is this really consistent with a scrolled client area, inner borders, swapped scrollbars in BiDi mode etc.?

But I agree that client areas *could* be described by TopLeft and BottomRight points, when the implementation is consistent. AFAIR there exist (derived) controls with a client origin (0,0)...

DoDi

ClientRect Left,Top is 0,0, so Right=ClientWidth and Bottom=ClientHeight.

What about the determination of the ScrollOffset:

function TScrollingWinControl.GetClientScrollOffset: TPoint;
begin
   if (HorzScrollBar  nil) and (VertScrollBar  nil) then
   begin
     Result.X := HorzScrollBar.Position;
     Result.Y := VertScrollBar.Position;
   end else
   begin
     Result.X := 0;
     Result.Y := 0;
   end;
end;

Does a scrolling control really *always* have two or zero scrollbars? If so, a check of only one scrollbar would be sufficient, otherwise every scrollbar must be checked individually!

DoDi

See e.g. TControlBorderSpacing. A comment also mentions that group boxes have their frame inside their client area.

The ClientRect excludes scrollbars and is relative to the left, top of the visible client area (so Left,Top are almost always 0,0). So for almost all uses it is simply the size of the visible area, where a control can paint and gets mouse events.

A control can paint everything within its *bounds*, e.g. frames and bevels. The *client area* is reserved for child controls, as the name indicates.

DoDi