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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
