[Lazarus] Autosize behaviour
Mattias Gärtner
nc-gaertnma at netcologne.de
Wed Apr 7 15:01:18 CEST 2010
Zitat von Michael Van Canneyt <michael at freepascal.org>:
>
>
> 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
More information about the Lazarus
mailing list