Datenaustausch mit Dialogen

Kramny

Hallo zusammen,

kann es sein, dass ich mich nur dämlich anstelle, oder wie funktioniert unter C# der Datenaustausch zwischen Dialogen. Im Netz habe ich zwar Beispiele gefunden und im Prinzip geht das ja auch ganz gut Objektorientiert. Ich vermisse nur etwas, das ich unter MFC kennen uns schätzen gelernt habe:

Unter MFC habe ich über den Assistenten zu einem Dialog eine Klasse erzeugt, anschließend Membervariablen zu einem Steuerlement hinzugefügt. Der Assisten hat mit dann folgenden Beispielcode erzeugt:

void MyDialog::DoDataExchange(CDataExchange* pDX)
{
	CDialog::DoDataExchange(pDX);
	DDX_Control(pDX, IDC_EDIT1, m_Textfeld);
	DDX_Control(pDX, IDC_CHECK1, m_Checkbox);
	DDX_Text(pDX, IDC_EDIT2, m_Wert);
	DDV_MinMaxInt(pDX, m_Wert, 10, 30);
}

Ich fand das ganz bequem, da hier z.B. ein Textfeld (IDC_EDIT2) direkt einer Int-Variable zugeordnet wurde und eine MinMax-Abfrage (hier zw. 10 und 30) implizit über den Aufruf MinMaxInt durchgeführt wird. Beim Verlassen des Dialogs wird DoDataExchange aufgerufen und alle betreffenden Steuerelemente ausgelsen (beim Starten werden sie entsprechend gesetzt).

Unter C# muss ich mir das Ganze selbst "zusammenbasteln". Kann mir einer erklären, ob und warum das nicht mehr in das C#/.NET-Konzept passt. Oder bin ich nur blind?

Vielen Dank,
Gruß Kramny

Deine Frage sollte eher lauten: Wie mache ich einen mfc-ähnliche Datenaustausch unter Windows Forms? C# ist genauso wie C eine Programmiersprache und keine Bibliothek mit der graphischen Benutzeroberflächen erstellt werden könnten.

Eine kurze Antwort auf Deine Frage: Das geht nicht.

Wenn du bei den Konzepten von MFC bleiben willst (inkl. Dokument/Ansicht-Architektur), dann musst du schon C weiterverwenden (s. http://msdn2.microsoft.com/de-de/library/1te0bbs8(VS.80).aspx). Windows Forms bieten diese Art von Funktionalität nicht. Und, um ehrlich zu sein, ich trauere dem dynamischen Datenaustausch auch nicht nach, wenn ich mit txtBenutzername.Text direkt auf den gewünschten Wert zugreifen kann.

Du kannst aber Properties verwenden, um zentrale Zugriffsschnittstellen zu definieren, z.B.

private string Benutzername {
get {return txtBenutzername.Text;}
set {txtBenutzername.Text = value;}
}

Der Vorteil besteht darin, dass Du hier weitere Funktionalität an zentraler Stelle hinterlegen kannst.

Kramny

Hallo maro158,

erstmal Danke. Natürlich könnte man die Frage auch anders formulieren. Im großen und Ganzen war es mir ja klar, dass es nicht (mehr) so geht. Das Warum ist mir nur nicht ganz klar.

Das heißt doch nur, dass ich für 125 Checkboxen (blödes Beispiel) 125 Properties (von Hand?)

public bool Cb1Checked
{
    get { return cb1.Checked; }
    set { cb1.Checked = value; }
}

erzeugen muss. Wenn man's richtig macht, muss zu jeder Property ja noch ein Kommentar (Aufwand!). Oder gearde wenn es um MinMax abfragen geht... Das klingt mir ziemlich nach Copy&Paste-Arbeit.

Nun gut, aber wie macht man denn nun eine, aus programmiertechnische Sicht, saubere Datenübergabe. Es gibt ja folgende Möglichkeiten:

1. So wie Du es beschrieben hast mit Properties, die direkt auf die Eiegenschaft (z.B. Checked oder Text) des Steuerelemets zugreift. Übrigens finde ich den Ansatz super - bin noch gar nicht von alleine darauf gekommen.

2. Man könnte in der Formularklasse private Membervariablen anlegen und den Zugriff auf diese mittels Properties regeln. Jetzt noch eine private Methode (z.B. UpdateAllControls()), welche die Daten zwischen den Steuerelementen und den Membervariablen austauscht.

3. Ein ein Objekt als Refernz, das alle notwendigen Variablen enthält, im Konstruktor übergeben und weiterverarbeiten. Nach Beenden des Dialogs, kann man die Variablen des übergebenen Objekts abfragen.

Technisch ist ja vieles möglich, aber was ist in der Praxis üblich? Oder anders gefragt: Gibt es ein gängiges Entwurfsmuster für Einstellungsdialoge?

Vielen Dank
Kramny

SeboStone

Blödsinn, Properties legt man nur an, wenn das Objekt auch mit anderen Objekten kommunizieren soll. Ansonsten wäre es sicherlich clever ein Datenobjekt zu erstellen, wenn man schon mit 125 Checkboxen, etc. rumhantieren will ... der arme User.

@Kramny:
Wenn wir bei Deinem Beispiel mit den CheckBoxen bleiben: Dafür gibt es Listen-Steuerelemente wie PropertyGrid, CheckedListBox, ListView oder DataGridView.
Was Du verwendest, hängt größtenteils davon ab, wie Du die Daten speichern willst/musst. Guck Dir mal folgenden Link an:
http://msdn2.microsoft.com/en-us/library/aa730869(vs.80).aspx

@SeboStone:
Kannst Du bitte erklären, was Du mit "Datenobjekt" meinst.

SeboStone

Du kapselst alle Daten die Du brauchst, für dieses Beispiel hier bauste Dir ein Objekt mit allen benannten Checkbox.Checked Variablen, oder ein Array wenn Dir Indizes reichen, dann ist aber wie Du schon erwähnt hast eine Liste das Beste. Das Objekt kannste dann an jede Form übergeben und drauf arbeiten. Ein Datenobjekt würde ich nehmen wenn es viele Daten unterschiedlichen Typs gibt.

Kramny

Hallo,

danke erstmal für die Antworten. Das mit den 125 Checkboxen war jedoch nur als extremes Beispiel gedacht um zu zeigen wie aufwändig der Code wird, wenn ich hier mit Properies arbeite. (in der MFC gibt es ja eben nurt eine Membervariable und eine Zeile für DDX.

Das mit der Objekt+übergabe habe ich auch schon ausprobiert. Geht natürlich, ein Objekt im Konstruktor mit den Parametern zu übergeben. Aber mich ärgert eigentlich, dass man von Visual Studio 2005 in C# rel. wenig (im gegensatz zu MFC) Unterstützung erhält - ist es doch aus meiner Sicht eine zielmlich gängige vorgehensweise.

Nehme gerne noch tipps entgegen. Bin heute leider etwas kurz angebunden.

Gruß
Kramny