Ausrichtung des Splitters unter Dot.Net

[Delbor]

Hi zusammen
Wie ich festgestellt habe, ist mein Problem uralt, wie dieser link beweist - gelöst scheint es für das DotNet-Framework 1.1 noch nicht zu sein( und wird es wohl auch nicht mehr).
Wie ich hier festgestellt habe, gäbe es sehr wohl eine Möglichkeit, unter BDS2006/Turbo Delphi-DotNet mit dem DotNet-Framework 2.0 zu arbeiten. Man müsste sich nur ganz sicher sein, dass keine Generics verwendet werden müssen.

Trotzdem noch mal kurz: das Problem ist ja, dass sich der Splitter in jedem Fall an Left (bzw. Top/Rigth oder Bottom) des Containers ausrichtet, statt, wie es der Delphi32-TSplitter tut, an der jeweiligen Position des nicht von weiteren Komponenten belegten Clientbereichs des Containers.

Hat irgendwer eine passable Lösung für dieses Problem bereit? Für allfällige Anregungen schon mal vielen Dank!

Gruss
Delbor

[SirThornberry]

Könntest du bitte den Titel ändern so das er aussagekräftig ist und man anhand des Titels weiß worum es geht? Danke!

[Delbor]

Hi zusammen
Inzwischen habe ich eine Antwort gefunden, die mir das Problem nicht löst, aber immerhin den Weg dazu aufzeigt.

Zum einen erstelle ich dynamisch Panels, auf denen ich ein oder mehrere RichTextBoxen ebenfalls dynamisch erstelle. Pro Panel entsteht so quasi eine "Tabellenzeile". Zwischen zwei so generierten Panels erzeuge ich jeweils einen Splitter, um die Höhe der Panels (und der Edits) zur Laufzeit ändern zu können. Dabei gilt folgendes: zuerst wird das Panel und die Edits erstellt, und erst danach der Splitter. Der soll zwar Top andocken, aber nicht im absoluten Top des Containers, sondern im ContainerTop plus der Höhe des erzeugten Panels. (Was er nicht tut).

Ähnliches habe ich per Drag&Drop zur Designzeit gemacht: zwei Panels auf der Form, getrennt durch einen Splitter. Wird dieser angelegt, klebt er sich erst mal Left an den Container, egal, ob da schon was ist oder nicht.
Lösung: rechte Maustaste > 'nach hinten setzen'.
Per Code müsste hier die Z-Order des Elements/der Elemente festgelegt werden. Nur - das einzige, was ich dazu fand, stammt aus der Win-API, was unter DotNet doch ziemlich daneben ist.

Weiss jemand, wie sich die Z-Ordnung unter DotNet beeinflussen lässt? Für eure Antworten schon mal fielen Dank!

Gruss
Delbor

[Elvis]

Zitat von Delbor:

Weiss jemand, wie sich die Z-Ordnung unter DotNet beeinflussen lässt?

Ein Control wird immer"obendrauf" eingefügt. Dadurch landet es auch ganz oben wenn alle Controls DockStyle.Top haben.
Du kannst ein Control nach vorne oder hinten holen, indem du BringToFront oder SendToBack aufrufst.

btw: DockStyle

btw2:

Zitat von Delbor:

Wie ich festgestellt habe, ist mein Problem uralt, wie dieser link beweist - gelöst scheint es für das DotNet-Framework 1.1 noch nicht zu sein( und wird es wohl auch nicht mehr).

Das hängt aber nicht mit dem Problem zusammen, sondern vielmehr mit dem Autor des Threads. Bei dem antworte ich höchstens aus Versehen.

[Delbor]

Hi zusammen

@ Elvis: Dein Hinweis hat mir sehr geholfen! Danke! Nun sieht die Sache wie folgt aus:

Delphi-Quellcode:

procedure TWinForm.MenItemFourCells_Click(sender: System.Object; e: System.EventArgs);
   var Pnl : System.Windows.Forms.Panel; RTFEdit: System.Windows.Forms.RichTextBox;SPL:System.Windows.Forms.Splitter;
       i: integer;
begin
   Pnl := PanelCreate(Pnl);
   Pnl.BringToFront;
   CreateHSplitter(SPL);
   SPL.BringToFront;

Damit wird bei jedem Proceduraufruf ein Panel erzeugt, an dessen unterem Rand aussen ein horizontaler Splitter klebt.Eine Besonderheit gibt's dabei allerdings: das oder die Panel(s) lassen sich zur Laufzeit nur so lange vergrössern, bis der unterste Rand den bei Dockpadding festgelegten Wert erreicht haben. Erstelle ich zur Laufzeit mehr Panels, als im Clientbereich angezeigt werden können, werden die Scrollbars aktiviert, und ich kann ohne Probleme scrollen - nur die Splitter funktionieren nicht mehr; das heisst, ich kann die Hoehe der Panels nicht mal mehr verkleinern.
Das aber eigentlich mehr so am Rande.
Vielmehr erstaunt mich nun folgendes:

Delphi-Quellcode:

      case i of
      1: begin
            ...........
            RTFEdit.Anchor := AnchorStyles.Top or AnchorStyles.Left or AnchorStyles.Bottom;;
            Pnl.Controls.Add(RTFEdit);
            RTFEdit.BringToFront; //
            CreateVSplitter(SPL);
            Pnl.Controls.Add(SPL);
            SPL.BringToFront;    //   //
         end;

in solchen Anweisungsblöcken erstelle ich pro Panel bis zu 4 RichEdits. Da ich jetzt auch gerne die Länge der einzelnen Edits zur Laufzeit ändern können möchte, füge ich auch hier Splitter dazu. Und zwar sollte der Spitter jeweils am zuletzt erstellten Edit kleben. Das tun die 'lieben Splitterchen' aber beileibe nicht. Stattdessen kleben sie Left am Panel, schön aufgereiht wie eine Perlenschnur. Und zwar hinter oder vor den Edits, je nachdem, ob ich einen oder beide der oben gezeigten 'BringtoFront'-Aufrufe ausklammere oder nicht

Da lob ich mir doch das gute alte Clientsystem von Borland!

Weiss jemand eine Antwort auf dieses merkwürdig Verhalten?

Zitat:

Ein Control wird immer"obendrauf" eingefügt. Dadurch landet es auch ganz oben wenn alle Controls DockStyle.Top haben.

Ich habe versuchsweise auch alle BringtoFront-Aufrufe durch SendoBack ersetzt - mit dem selben Effekt: alle Splitter kleben ganz links am Container, nur das sie jetzt unter den Edits angeordnet sind.

Für eure Antworten schon mal vielen Dank!

Gruss
Delbor