vordrängelnde Controls (Control.Dock)
Hallo Community,
habt ihr eine schlaue Erklärung dafür, warum bei
ctrlCurr = new Panel ();
ctrlCurr.BackColor = Color.Red;
ctrlCurr.Dock = DockStyle.Left;
Controls.Add (ctrlCurr);
ctrlCurr = new Panel ();
ctrlCurr.BackColor = Color.Green;
ctrlCurr.Dock = DockStyle.Left;
Controls.Add (ctrlCurr);
das zweite, grüne Panel weiter links angezeigt wird?
Ich finde das wenig intuitiv, dass sich ein "späteres" Control an dem schon erzeugen (nach links) vorbeidrängelt.
Außerdem führt das dazu, dass man z.B. bei AddRange die Controls genau in der umgekehrten Reihenfolge angebenen muss als sie erscheinen.
Vielleicht kann ich besser damit leben, wenn ich eine überzeugende Erklärung bekommen, warum das so sein muss.
Und gleich noch eine zweite Frage: Kann man beim Docking eine Rand/Abstand angeben/definieren oder werden die Controls immer direkt aneinander gequetscht? (Mir ist klar, dass es außer Control.Dock auch Control.Anchor gibt, womit man Ränder realisieren kann, trotzdem).
Vielen Dank!
herbivore
Die Reihenfolge beim Docking mehrerer Controls ergibt sich aus dem Z-Index, der mit "nach vorne/hinten stellen" (oder so ähnlich) bzw. BringToFront/SendToBack beeinflusst werden kann.
Hallo bitstream,
danke, das ist schon klar.
Dadurch wird es aber vor allem eher noch unverständlicher:
Erstens ist unverständlich, warum ein später erzeugtes Control in der Z-Order weiter hinten eingeordnert wird (also u.U. von den den vorher erzeugten verdeckt).
Und was das Docking angeht ist dann erst recht unverständlich, warum sich ein weiter hinten befindliches (also quasi unwichtiges) Control sich vordrängeln darf.
herbivore
Zumindest behauptet hier
microsoft das folgende:
When a control is docked to an edge of its container, it is always positioned flush against that edge when the container is resized. If more than one control is docked to an edge, the controls appear side by side according to their z-order; controls higher in the z-order are positioned farther from the container's edge.
EDIT:
Eine kleine interessante Diskussion darüber existiert auch hier:
Kernaussage: Mehr Flexibilität:
admit they could have made this a bit more intelligent, but now it is very flexible.
Suppose you have a 3rd panel that need to be docked on the bottom on the form.
Now you can control wether that panel will occupy the complete bottom of the form,
or just the remaining part after the 2nd panel has docked to the right.
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
Hallo dr4g0n76,
das besagt aber beides nur, dass die Z-Order einen Einfluss hat. Soweit waren wir ja schon und dass die Z-Order einen Einfluss hat, ist ja auch ok und bringt Flexibilität. Die Frage ist eben nur, warum die Z-Order in genau der umgekehrten Reihenfolge berücksichtigt wird, als ich (und scheinbar noch viele andere) das erwarten würde.
Also spekulieren kann ich darüber natürlich auch. So gehe ich z.B. davon aus, dass Controls, die später erzeugt werden, einen Z-Order-Wert zugewiesen bekommen, der eins höher ist, als der aller bisher erzeugten Controls. Wenn man nun höher mit wichtiger gleichsetzt, hätte man schon die Erklärung. Da aber Controls mit höherem Z-Order-Wert weiter hinten - und damit u.U. auch teilweise oder ganz durch weiter vorne liegende Controls verdeckt - angezeigt werden, bedeutet höher hier aber unwichtiger. Ich denke, dass wurde bei der Programmierung nicht ausreichend bedacht. Und das führt dann zu den oben beschriebenen negativen oder zumindest verwirrenden Effekten.
Aber das ist wie gesagt eine Spekulation. Und Spekulieren nützt nur beschränkt. Deshalb wäre meine Frage also, wer weiß warum das so realisiert wurde.
Vielleicht sehe ich auch einfach den Vorteil der ganzen Geschichte nicht. Deshalb wäre meine Frage also, wer weiß welchen Vorteil es hat, dass die Z-Order in dieser (umgekehrten) Weise Einfluss hat.
herbivore
Wozu muss man das wissen?
Es ist eh nicht zu ändern, also nimm es hin.
Und solltest Du irgendwann mal VS.NET benutzen, dann hast Du einen eigenen
Editor( View/Other Windows/Document outline), mit dem Du die Z-Order editieren kannst.
Hallo FZelle,
Wozu muss man das wissen?
Wissen muss man das nicht. Aber es hat mich interessiert und deshalb habe ich gefragt. Das halte ich für legitim.
Und solltest Du irgendwann mal VS.NET benutzen, dann hast Du einen eigenen
Editor( View/Other Windows/Document outline), mit dem Du die Z-Order editieren kannst.
Ohne VS (also direkt im Code) kann ich die Z-Order wesentlich leichter editieren/beeinflussen.
herbivore
Hallo zusammen,
ich denke, ich habe die Erklärung gefunden. Win32 (worauf ja .NET basiert) liegt ein "normales" Koordinatensystem zugrunde, d.h. der Ursprung (0,0,0) ist unten links - und nach recht, nach oben und nach hinten(!) (also vom Anwender weg) steigen die XYZ-Werte an. Eben ganz so, wie das in der Mathematik verbreitet ist.
Wenn bei Win32 die Z-Werte mit 0 beginnen aufsteigend vergeben werden, ist es in der Tat so, dass sich später hinzugefügte Controls weiter hinten befinden.
Nun hat sich gezeigt, dass es für das Entwerfen von Forms günstiger ist, wenn der Ursprung oben links und die XY-Werte nach unten und nach rechts wachsen. Und so wurde das ja in .NET ja auch umgesetzt (per interner Koordinatenumrechnung). Eigentlich wäre es auch sinnvoll, wenn die Z-Werte nach vorne (also zum Anwender hin) wachsen. Aber das scheint man eben nicht umgesetzt, sondern wie bei Win32 belassen zu haben. Ich kann nur spekulieren, ob aus Versehen oder mit Absicht.
herbivore