C# Oberfläche aufteilen?

[sunnyandy]

Hallo,

ich möchte gern wissen, ob es in C# die Möglichkeit gibt, den Code zum Anzeigen der Oberläche in mehrere Klassen aufzuteilen.
In Java habe ich zum Beispiel die Oberfläche in mehrere Panels aufgeteilt und diese in einzelnen Klassen beschrieben, die Unterklassen von Swing.Panel waren.
Wenn ich dann das Panel auf die Oberfläche setzen wollte zum Anzeigen, habe ich einfach die Klasse angegeben, die das Panel beschreibt.

Geht sowas in C# auch?

Was ich aufteilen möchte, ist also der Code zum Erstellen der Oberfläche (die View aus dem MVC-Muster).

Ich hoffe, ihr könnt mir weiterhelfen!
Danke im Voraus!
Grüße, Andy

[Jürgen Thomas]

Hallo,

wenn Du das Stichwort Panel benutzt, dann kann ich eindeutig sagen: Ja, es ist (genauso) möglich. Ob es sinnvoll ist, hängt von der praktischen Zielsetzung ab.

Zunächst ein Gesichtspunkt, der mit Deiner Frage noch wenig zu tun, aber u.U. mit der Lösung: Ein Grundgedanke unter NET 2.0 ist die partial class. In Form1.Designer.cs steht alles, was der Designer für die Darstellung des Formulars benutzt; in Form1.cs steht alles, was Du selbst innerhalb des Formulars regelst. Diese Aufteilung kannst Du noch weitertreiben, z.B. indem Du in Form1.Panel1.cs alles einbaust, was Du mit Panel1 machst.

Hinweis: Diese weitere Aufteilung wird nicht empfohlen; sie kann aber hilfreich sein.

Deine eigentliche Frage wird mit dem UserControl beantwortet: Du kannst in mehrere getrennten Klassen Panel1 bis Panel7 jeweils in ein UserControl einbinden und diese je nach Bedarf im Formular zusammenführen.

Gruß Jürgen

[Smash]

Diese Technik wäre für mich ebenfalls interrasant. Ich hätte allerdings noch Fragen zur Vorgehensweise.

Ich habe eine UserForm mit einem TreeView das als Auswahl dient. Je nach Auswahl im TV soll eine andere GroupBox geladen werden.

1.
- Muss ich eine Klasse für jede GroupBox erstellen die von der Klasse GroupBox erbt?

2.
- Kann ich den die Einzelnen GroupBoxen dann irgendwie im Designer sehen (MS VC# Express)?

3.
- Kommen die Steuerelemente der GroupBox in die Klasse der GroupBox und sind die Positionsangaben relativ zur GroupBox?

Vielen Dank im Voraus.

[Bernhard Geyer]

> Ein Grundgedanke unter NET 2.0 ist die partial class. In Form1.Designer.cs steht alles, was der Designer für die Darstellung des Formulars benutzt; in Form1.cs steht alles, was Du selbst innerhalb des Formulars regelst.

Letzendlich wird wieder das nachgebaut was Delphi schon seit über 10 Jahren mit den DFM-Formularen hat. Jedoch mit Modernen Mitteln. Für mehr als für den Designer halte ich diese Methode eher für verwirrent. Eine Klasse die 10.000 Zeilen umfaßt deutet eher auf eine nötige Refakturierung hin als das man die Funktionalität auf mehrer Units "Versteckt".

> Du kannst in mehrere getrennten Klassen Panel1 bis Panel7 jeweils in ein UserControl einbinden und diese je nach Bedarf im Formular zusammenführen.

Ist m.E. die Sinnvollere Lösung. Wenn du auch noch geschickt vorgehst kannst du eine Wiederverwendung erreichen. Verwenden ein ähnliches Konzept auf Formularbasis seit mehrern Jahren erfolgreich unter Delphi.

[Andreas Kosch]

Hallo Bernhard,

Letzendlich wird wieder das nachgebaut was Delphi schon seit über 10 Jahren mit den DFM-Formularen hat

und Borland Delphi 1 hat nur das nachgebaut, was Microsoft Visual Basic 1 vorgemacht hat: Trennung von Formular-Layout und Quelltext in verschiedene Dateien ;-)

In .NET 1.x hatte man das Layout in den Regionen der Quelltextdatei versteckt. Aber durch die partitiellen Klassen von .NET 2.0 (die an anderen Stellen viel nützlicher sind als bei den Windows Forms) gab es in Visual Studio 2005 nun eine bessere Stelle als die Quelltext-Regionen.

[Bernhard Geyer]

und Borland Delphi 1 hat nur das nachgebaut, was Microsoft Visual Basic 1 vorgemacht hat: Trennung von Formular-Layout und Quelltext in verschiedene Dateien ;-)

Mist, es hat jemand gemerkt

Aber durch die partitiellen Klassen von .NET 2.0 (die an anderen Stellen viel nützlicher sind als bei den Windows Forms)

Könntest Du mir Stellen nennen wo dies der Fall ist und den damit verbundenen Vorteil? Mir erschließt sich der allgemeine Vorteil davon nicht so richtig.

[Andreas Kosch]

Hallo Bernhard,

Könntest Du mir Stellen nennen wo dies der Fall ist und den damit verbundenen Vorteil?

die partitiellen Klassen sind immer dort von Vorteil, wo Generatoren einen Teil des Quelltextes erzeugen. Das beste Beispiel ist das typisierte DataSet. Das Ergebnis der visuellen Konfiguration im DataSet-Designer von Visual Studio 2005 (oder das Ergebnis von XSD.EXE) landet in der xyz.Designer.cs, während die vom Entwickler vorgenommenen Erweiterungen in der anderen partiellen Klasse xyz.cs vorgenommen werden. Wird danach das typisierte DataSet über den Designer (oder XSD.EXE) neu aufgebaut, gehen die vom Entwickler vorgenommenen Erweiterungen nicht verloren. Im Gegensatz dazu hatte früher in .NET 1.x eine eigene Erweiterung am typisierten DataSet den nächsten Generatoraufruf nicht überlebt.

[Bernhard Geyer]

OK, kapiert. Überall wo automatisch generierte SW-Teile auftauchen werden die in einer eigenen Unit gepackt wo sinnvollerweise die ersten Zeilen einen Kommentar darstellen das man doch bitte hier nichts ändern sollte da diese Source u.U. wieder überschrieben wird. Ist sinnvoll. Damit tut sich auch die SW-Einfacher indem die Unit komplett erzeugt wird anstatt in irgendeiner Region was zu ändern wo evtl. versehentlich man was selbst ergänzt hat.