[Lazarus] Autosize behaviour

Hans-Peter Diettrich DrDiettrich1 at aol.com
Thu Apr 8 00:20:32 CEST 2010


Michael Van Canneyt schrieb:

> "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.

BorderSpacing and ChildSizing IMO are specific to an layout manager, 
meaningless to other layout managers. BorderSpacing IMO is equivalent to 
the Delphi anchors.


> 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.

It's not that different. Let's separate containers from other controls:

Containers (currently) are windowed controls which can have child 
controls. They must not necessarily be windowed, but they may have their 
own layout manager.

Other controls can be windowed, depending on the widgetset(?), but are 
not designed to act as containers for other controls.

Both types have a method to determine their preferred size, either 
themselves or by asking their layout manager. When such controls are 
aligned or anchored, they only have one degree of freedom for autosize - 
this eventually must be handled in the outer layout manager, which can 
ignore the preferred size of its client controls.

> 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.

No control can have two AutoSize properties at the same time, so it's 
okay to have a single property - the rest is polymorphism.


>>> 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.

The interface between controls and layout manager has to be defined. 
Depending on the layout type, a control can have a designed size, and a 
preferred size (including autosize), and it can have a forced size, with 
the extent in one direction determined by the container, and a final 
BoundsRect when the layout is finished. Every visual control must be 
able to calculate and return these different sizes. A layout manager 
uses the appropriate sizes of its client controls, in addition to 
eventual anchors, in order to figure out the layout, and then determines 
the BoundsRect of every client. Eventually the controls are allowed to 
adjust or align themselves within the assigned BoundsRect (cell of a 
stripe or grid layout), but this better should be done by the layout 
manager (for ChildSizing).

The "Individual cells" sizing IMO should not be supported, it only looks 
ugly; a user supplied alCustom handler could implement such irregular 
behaviour, if a user insists in such a feature. Also 
BoundsRectForNewParent can be dropped, it's useless in tree docking. The 
same for related calculations, marked as "increase chance that the 
width/height is kept". All this can be done in an specific DockManager, 
and in the current DragDockObject.

DoDi





More information about the Lazarus mailing list