Hi,

I came across something unexpected today. I was under the impression that the order in which you set the Align property, that's the order in which the components align themselves with the parent and neighbouring components.

In this example, I have a Form with two Panels (P1 & P2). Order in which I did things:
* Create new Form
* Drop panel P1 on the Form
* Set P1.Align := alRight
* Drop panel P2 on the Form
* Set P2.Align := alBottom.

What I expected was Figure 1, where P1 is the full height of the form and P2 is the Width of the Form minus P1.Width. But instead I got Figure 2. I tried this in both Delphi 7 and Lazarus. It seems the alignment order is irrelevant to the component creation order or irrelevant to what order you set the Align properties. If fact, alignment is always process in the following hard-coded order: Top, Bottom, Left, Right, Client...

As I said, for some reason I was under the impression (even from delphi days) that the order in which you activate the Align properties, that's the order in which the alignment is applied. So what must I do to get Figure 1? Use Anchor's instead of Align properties?

[... you need a mono font to see ascii art...]

Figure 1:
+-------------+-------+
| | |
| | |
| client | P1 |
| | |
| | |
| | |
+-------------+ |
| P2 | |
+-------------+-------+

Figure 2:
+-------------+-------+
| | |
| | |
| client | P1 |
| | |
| | |
| | |
+-------------+-------+
| P2 |
+---------------------+

You need following:
1. Drop additional panel (P3) on Form
2. Make its border invisible and Aligh = alLeft
3. Drop P2 on P3 and make P2.Aligh = alBottom
4. Drop P1 on Form and make P1.Aligh = alRight

As I know, it is the only way...

2010/10/4 Graeme Geldenhuys

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101004/121ae834/attachment.html>

2010/10/4 ??????? ???????? :

Thanks I tried that, but there is a minor correction. P3 must be alClient, not alLeft.

Now it looks like I wanted, but that's a really odd way of having to do it. I would think creation order, or the order in which you set Align would make a lot more sense - and reduce the amount of components (resources) required to accomplish the same result. I guess Borland was smoking something illegal the day they implemented the Align property. :-)

Thanks again for the response.

I think it rather stems from the Windows world rather than Borland's bright minds. AFAIK it always was: horizontal takes precedence on vertical. So Top/Bottom fills entire width, Left/Right takes the remaining height, Client fill's the rest.

kind regards,
Dimitri Smits

Not really.

The problem is that there is no 'creation order'. The streaming system doesn't guarantee you in which order components are created. Therefor, the 'order of setting the align property' is not well-defined, and therefor is not taken into account when doing layouting.

Michael.

Dimitri Smits wrote

I think it rather stems from the Windows world rather than Borland's bright minds. AFAIK it always was: horizontal takes precedence on vertical. So Top/Bottom fills entire width, Left/Right takes the remaining height, Client fill's the rest.

I got a reply from Michael van Canneyt in private. He said as far as he knows it's due to the streaming system used in the VCL. So "order of creation" is never guaranteed, and can never make assumptions about that. So a hard-coded top,bottom,left,right,client processing order was put it place.

What is weird is that neither Delphi, nor Kylix, nor LCL help mentions this hard-coded order of processing. At least the LCL TAlign help mentions the possible issue of "order of precedence", but doesn't actually give the answer or reasoning why it exists.

Zitat von Graeme Geldenhuys :

You can not use the creation order, because it is fixed. This would make it impossible to drag a control in the designer to another position.

The order in which you set Align is a bad idea, because
1. it needs a new property to store that
2. it is not clear/intuitive what should happen when you drag a control in the designer.

Borland implemented a limited, but visually easy to understand system.

IMO Borland did a few things wrong, but Align was a good idea. Of course adding an optional more flexible layout engine would be an even better idea.

Mattias

Zitat von Graeme Geldenhuys :

To clarify:
The order of creation is fixed (in the sense of determinate). It is a stream after all.
What Michael meant is that creation order can get complicated, e.g. with inheritance, frames and special components auto creating their children and that some designer operations change creation order. Therefore you should not use creation order for anything else than for creation issues.

The wiki describes the algorithm with examples:
http://wiki.lazarus.freepascal.org/Autosize_/_Layout#Align

The property should probably link to the corresponding wiki page. Or better: Integrate the wiki content and the fpdoc entries.

Mattias

2010/10/4 Mattias G?rtner :

The wiki describes the algorithm with examples: http://wiki.lazarus.freepascal.org/Autosize_/_Layout#Align

Very clear help indeed. That's even better help that Borland or Embarcadero could create. Well done! :)

The property should probably link to the corresponding wiki page. Or better: Integrate the wiki content and the fpdoc entries.

Yes the same old problem of having to many location for similar topics. Information now gets lots because it is fragmented all over the place. Such documentation should rather have been in the fpdoc help (class documentation where it belongs).

Borland implemented a limited, but visually easy to understand system. IMO Borland did a few things wrong, but Align was a good idea.

I like it, because it keeps things simple :-)

Of course adding an optional more flexible layout engine would be an even better idea.

We already have different layout managers, some of which are called "docking managers" - what IMO is wrong when they do not really handle drag-dock operations. A docking manager is a layout manager, that *also* allows to add/remove components interactively.

The handling of Add, Remove and Resize events is a common task of all layout managers, and it's unimportant *how* these events occured (in code or interactivly). A form designer also is kind of an docking manager, with only a different persistency model (component streaming) for the final state.

It would not be very complicated to retype the DockManager property into TLayoutManager, with extensions for *all* tasks of an layout manager, in addition to the drag-dock handling. The only purpose of the DockSite property would be to enable/disable drag-dock features, activating the drag manager for that component. There is no special use for the UseDockManager property, except that it un/installs an non-default layout manager when changed. The DockClient* properties become obsolete, because all child controls are managed by an layout manager in any case; all additional layout information, used by e.g. anchor- or other docking/layout managers, can be moved out of the controls, into the layout manager class(es) - see TDockZone.

DoDi