Wie erstellt man eine Baumansicht-Präferenzdialogart-Schnittstelle in C#?

Question

Ich schreibe eine Anwendung, die im Grunde nur ein Einstellungsdialog ist, ähnlich dem Baumansicht-Einstellungsdialog, den Visual Studio selbst verwendet. Die Funktion der Anwendung ist einfach ein Durchgang für Daten von einem seriellen Gerät zu einer Datei. Es führt viele, viele Transformationen an den Daten durch, bevor es sie in die Datei schreibt, daher ist die GUI für die Anwendung einfach alle Einstellungen, die festlegen, welche Transformationen durchgeführt werden sollen.

Was ist der beste Weg, um einen Baumansicht-Einstellungsdialog zu entwerfen/zu codieren? Der Weg, den ich gegangen bin, besteht darin, das Hauptfenster mit einem angedockten Baumsteuerelement auf der linken Seite zu erstellen. Dann erstelle ich Containersteuerelemente, die jedem Knoten des Baums entsprechen. Wenn ein Knoten ausgewählt ist, bringt die App das entsprechende Containersteuerelement dieses Knotens nach vorne, verschiebt es an die richtige Position und maximiert es im Hauptfenster. Dies scheint beim Entwerfen wirklich umständlich zu sein. Das bedeutet im Grunde, dass ich während des Entwurfs viele Containersteuerelemente jenseits des Randes des Hauptfensters habe, zu denen ich scrollen muss, um damit zu arbeiten. Ich weiß nicht, ob das so total Sinn macht, wie ich darüber schreibe, aber vielleicht wird es durch diese Visualisierung verständlicher:

Im Grunde muss ich mit diesem riesigen Formular arbeiten, mit Containersteuerelementen überall, und dann eine Menge Formatierungen zur Laufzeit durchführen, um alles zum Laufen zu bringen. Dies scheint eine Menge zusätzlicher Arbeit zu sein. Mache ich das auf völlig dumme Weise? Gibt es einen "offensichtlichen" einfacheren Weg, den ich übersehe?

Answer 1

Ein ordentlicher Weg besteht darin, separate Formulare für jeden 'Bereich' zu erstellen und in jedem Konstruktor des Formulars festzulegen

this.TopLevel = false;
this.FormBorderStyle = FormBorderStyle.None;
this.Dock = DockStyle.Fill;

Auf diese Weise können diese Formulare jeweils in ihrem eigenen Designer angeordnet, zur Laufzeit instanziiert und dem leeren Bereich wie ein normales Steuerelement hinzugefügt werden.

Vielleicht könnte das Hauptformular eine SplitContainer mit einem statischen TreeView in einem Bereich und Platz zum Hinzufügen dieser Formulare im anderen verwenden. Sobald sie hinzugefügt sind, könnten sie mit den Methoden Hide/Show oder BringToFront/SendToBack durchgeblättert werden.

SeparateForm f = new SeparateForm(); 
MainFormSplitContainer.Panel2.Controls.Add(f); 
f.Show();

Answer 2

Greg Hurlman schrieb:

Warum nicht einfach den entsprechenden Container anzeigen/ausblenden, wenn ein Knoten im Raster ausgewählt ist? Die Container alle passend dimensionieren und alle außer dem Standard ausblenden, der beim Laden im Raster vorab ausgewählt wird.

Leider ist das genau das, was ich vermeiden will. Ich suche nach einer einfachen Möglichkeit, das Interface während des Designzeitpunkts zu handhaben, ohne dass beim Ausführen des Codes eine minimale Neugestaltung erforderlich ist.

Ich mag Duncans Antwort, weil sie bedeutet, dass das Design der Benutzeroberfläche jedes Knotens völlig separat gehalten werden kann. Das bedeutet, dass ich keine Überlappungen bei den Rasterlinien und anderen Vorteilen während des Designzeitpunkts bekomme.

Answer 3

Ich würde wahrscheinlich mehrere Panel-Klassen basierend auf einer Basisklasse erstellen, die von CustomControl erbt. Diese Steuerelemente hätten dann Methoden wie Speichern/Laden und ähnliches. Wenn ja, kann ich jedes dieser Panels separat entwerfen.

Ich habe einen Wizard-Steuerung verwendet, die im Design-Modus mehrere Seiten verarbeitet hat, so dass man im Designer auf Weiter klicken und alle Seiten gleichzeitig durch den Designer entwerfen konnte. Obwohl dies mehrere Nachteile hatte beim Verbinden von Code mit den Steuerelementen, bedeutet es wahrscheinlich, dass man eine ähnliche Einrichtung haben könnte, indem man einige Designer-Klassen erstellt. Ich habe selbst noch nie irgendwelche Designer-Klassen in VS geschrieben, also kann ich nicht sagen, wie oder ob es sich lohnt :-)

Ich bin ein wenig neugierig, wie du beabsichtigst, das Laden/Speichern von Werten zu/von den Steuerelementen zu handhaben? Es muss eine Menge Code in einer Klasse geben, wenn alle deine Seiten in einem großen Formular sind?

Und noch eine andere Möglichkeit wäre natürlich, den GUI-Code zu generieren, wenn jede Seite angefordert wird, unter Verwendung von Informationen darüber, welche Art von Einstellungen es gibt.