Reihenfolge von zur Laufzeit erstellten Komponenten mit Align=alTop

[shmia]

Beim TSplitter handelt es sich in der Tat um eine Ausnahme; hier darf man auch 3 Controls auf einen Container packen.

Zitat von CCRDude:

...aber dann gäbe es doch immer noch mindestens 5 stabile Controls statt nur 2? alTop, alLeft, alRight und alBottom sind ja auch zusammen angewandt um ein Align = alClient immer noch "stabil".

Die Frage ist dann nur, welches Control darf die Ecken beanspruchen und welches Control wird aus der Ecke verdrängt?
Hier gilt dann das Prinzip "wer zuerst kommt mahlt zuerst".
Das bedeutet die Erstellungsreihenfolge der Controls hat direkten Einfluss auf das Layout.
Sollte ein Control, und sei es nur kurzzeitig, unsichtbar geschaltet werden und danach wieder sichtbar (Visible := True) dann hat es seine Position im Layout verloren
und die Anordnung hat sich geändert.
Das meine ich mit Unstabil.
Bei zwei Controls ist die Erstellungsreihenfolge unerheblich; die Kombination aus (alTop|alLeft|alRight|alBottom) zusammen mit alClient ist immer stabil.

[CCRDude]

Und TActionMainMenuBar plus TActionToolbar sind dann die nächste Ausnahme, und dann gibt es noch diese Ausnahme, und jene...?

Die Ecken hängen bei Align nicht von der Erstellungsreihenfolge ab, da gibt es afaik eine definierte Reihenfolge, ich glaube alTop und alBottom haben Vorrang vor alLeft und alRight.

Natürlich bestehen die Problematiken, die Du erwähnt hast: unsichtbarschalten etwa.

Aber: die existieren nur, wenn man etwa Visible ändert. Das macht die VCL nicht von alleine. Und ob das unstabil oder nicht ist, hängt also davon ab, ob man mit eigenem Code etwas berücksichtigt, was eigener Code verursacht. Das ist für mich weit an der Definitiv von "unstabil" vorbei!

Egal, den Kern hast Du ja erwähnt - die Erstellungsreihenfolge. Danach fragte ich ja - wie ist das VCL-intern beim Formerstellen zur Laufzeit geregelt (die ist mMn sehr stabil und reproduzierbar) und was ist daran anders als an meiner dynamischen Erzeugung?

[SirThornberry]

Wenn man zur Designzeit etwas aufs Form packt wird doch auch "Top" mit abgespeichert.
Dadurch klappt das auch mit der Positionierung.
Die Erstellungsreihenfolge ist dabei egal denn das Align wird nicht ausgeführt wenn ein neues Control hinzu kommt sondern erst wenn Handles angefordert werden etc.
Das kann man wunderbar beobachten wenn man ein Control dynamisch erzeugt, den Align-Wert setzt und direkt danach Top/Left/Width/Height ausliest. Diese Werte ändern sich frühestens wenn das nächste mal Messages abgearbeitet werden oder eben durch einen manuellen Aufruf von ReAlign

[stahli]

M.E. wurde das Verhalten "irgendwann einmal" in Delphi geändert (in diesem Punkt verschlechtert).
Ich denke, früher war es so, dass beim Align die "ursprüngliche" Position den Komponenten (Top, Left) zu Ausrichtung herangezogen wurden.
Heute wird die "aktuelle" Position verwendet. Wenn man nun ein Control unsichtbar und dann wieder sichtbar macht, verschieben sich die Reihenfolgen, da sich die anderen Controls zischenzeitlich verschoben wurden.
Bei solchen Anforderungen setze ich die Höhe des Auszublendenden Controls inzwischen manchmal auf 0 und dann wieder zurück.

Ich meine früher, war das Verhalten der VCL in diesem Punkt vorhersehbarer und besser.

[Uwe Raabe]

Eine ähnliche Frage gab es auch mal bei Stackoverflow.

[CCRDude]

Nachdem ich an ursprünglicher Stelle auf anderes Alignment umgestiegen bin, kam ich heute wieder drauf, und habe das Problem dank diesem Thread nochmal überdacht. Insbesondere danke für den letzten Link zu Stackoverflow!

Mit reversem Setzen des Top auf 0 oder negative Werte konnte ich zwar nichts erreichen, wohl aber mit folgendem kleinen Helfer:

Delphi-Quellcode:

procedure ArrangeTControlTopOrder(AControls: array of TControl);
var
   i: integer;
begin
   if Length(AControls) = 0 then begin
      Exit;
   end;
   AControls[0].Top := 0;
   for i := 1 to Pred(Length(AControls)) do begin
      AControls[i].Top := AControls[i - 1].Top + AControls[i - 1].Height;
   end;
end;