Zitat von Michael Van Canneyt <[email protected]>:
On Wed, 7 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
IMO it's quite simple. A layout affects the position of child
controls inside a container control, nothing else. Borders,
Constraints and Autosize are general properties of all controls,
which must be handled in/by the control itself.
I agree for Constraints, but not the other two.
It is in contradiction with what Mattias said, where he claimed that
when doing layouting you must always work inside-out and outside-in.
Borderspacing IS used when layouting: it determines the available space
for childs inside/outside the control.
The control determines its client extent from given bounds, by
taking into account its specified border style. A layout manager
has no idea of such borders, bevels etc., and also not of the
visible rectangle of a TScrollingWindowControl.
From
http://wiki.lazarus.freepascal.org/Autosize_/_Layout#Align_and_BorderSpacing
"The space of BorderSpacing and of the parent's ChildSizing is applied to
aligned controls. The memo below has Align=alClient"
BorderSpacing has nothing to do with border style or bevels. It is an EXTRA
margin. Border style and bevels determine the ClientRect of a control, and
as Mattias said, they must be queried from the control itself.
BorderStyle and bevels are normally the frame. The ClientRect is the
inside (excluding the frame). The BoundsRect is the outside (including
the frame).
BorderSpacing the is the space around a control. It is a layouter
thing. The LCL layouters use the BorderSpacing properties as minimum
space between the controls (BoundsRects).
Autosize as well: if autosize is true, then the size of the control
changes, and therefor the layout internal to the control, but also
externally. Hence it belongs in the layouter.
That's right. You must disable AutoSize for all child controls when
using a custom layouter. Otherwise you create an endless loop.
In the simplest case the layouter has not to care about autosize at
all. The control determines its required extent, based on e.g. font
size and nationalized text, and reports it as its required extent.
There is nothing beyond that extent that a layout manager has to
know about.
Only when a control can adopt itself to different *given* extents,
by e.g. breaking its content into multiple lines, a layout manager
has to split the available extent into zones for the client
controls. Such a layout manager would accept an extent in one
direction, and calculate the resulting extent in the other
direction, or spread the client controls evenly. This is a
different behaviour from the beforementioned Autosize of controls
with no child controls.
AutoSize for a panel explicitly is about child controls, and therefor
layouting.
Unfortunately Borland used AutoSize for 2 different things:
- Resize control to accomodate child controls (as e.g. in TPanel)
- To accomodate for 'native content', such as in TLabel.
They should have been separate properties. I am talking only about
the first one. The second one, obviously, is only necessary for the
control itself.
Sorry, but separating makes no sense.
Many controls consists of several parts. A Combobox of an edit field
and a button. A TLabel consists of letters.
IMHO a control needs only 5 properties: top/left/width,height and
constraints. All the rest is layouting.
You mean that every control should have borders or bevels, as
specified by the layout manager? How should such a manager know
about different border styles for its client controls?
It does not need to. ClientRect is used for this.
Mattias
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
