Daten an Dialoge übergeben (Konstruktor)

Hades+

Hallo!

Ich möchte meinen Dialogen beim Aufruf ein paar Variablen übergeben, damit der Dialog weiß, welchen Datensatz er zu bearbeiten hat und in welchen Datensatz der Nutzer etwas einträgt. Wie kann ich beim Aufruf des Dialoges Variablen übergeben, bzw. wie implementiere ich das in dem aufgerufenen Dialog?

Danke im Voraus!!

Specialguest

Hallo

Du kannst beim Aufruf des neuen Dialoges ( DoModal() ), diesen Werte von deinen Basisdialog oder deiner SDI/MDI anwendung mitgeben!

#include "CDeineHeaderdesNeuenDialoges.h"
..
..
CDeineKlasse::OnNeuerButtonDialog()
{
  DeineHeaderdesNeuenDialoges dlg;
  dlg.WertInDerNeuenKlasse = WertDerÜbergebenWerdenSoll;
  dlg.DoModal();
}

oder falls ich es falsch verstanden habe und du eine reine dialoganwendung mit nur einen Dialog hast, kannst du dort in der Methode OnInitDialog() Werte für dein Dialog angeben!

hoffe das ich dir helfen konnte!

sven

ethereal

Ich glaube, du hast da bei deinen Bezeichnern
CDeineHeaderdesNeuenDialoges und DeineHeaderdesNeuenDialoges vertauscht. Klassen tragen bei der MFC für gewöhnlich das C davor, also sollte von CDeineHeaderdesNeuenDialoges eine Instanz angelegt werden. Dagegen werden die Dateien ohne das vorangestellte C erstellt, demzufolge sollte die
DeineHeaderdesNeuenDialoges.h-Datei eingebunden werden.

Specialguest

@ethereal
hast natürlich recht muss wohl irgendwie Fusseln im Kopf gehabt haben!

*werd mich bessern*

sven

Ernsti

ich würde einfach nur einen pointer auf den aufrufenden dialog/klasse mitgeben, und damit die daten holen.

estartu

Es gibt zwei Möglichkeiten:

Du gibst die Werte dem Konstruktor mit:

CDeinDlg::CDeinDlg(int f_nDatensatzID)
    : m_nDatensatzID(f_nDatensatzID) // in die Membervariable im Dialog übertragen
{
    // und was sonst noch zu tun ist...
}

Oder du versteckst DoModal (es geht, aber ich suche auch noch wie) und schreibst deine Eigene Funktion mit Parameter, die den überträgt und dann Domodal aufruft.

BOA

Ernsti schrieb:

ich würde einfach nur einen pointer auf den aufrufenden dialog/klasse mitgeben, und damit die daten holen.

Aloha,

kommt zwar immer auf den speziellen Fall an, ist aber die schönste Lösung.

Weil in der Variante von SpecialGuest müssen die Members auch public sein, bzw. zumindestens ne friend klasse drausgemacht werden.

Und was haben wir über Members gelernt ?

Vor allen Dingen gibt Dir die MFC alles vor, wenn Du einen Dialog bastelst.

Im Standardkonstruktor steht ja schon

CWnd* pParent = NULL

Nur noch passend gecastet und schon haste Zugriff auf alle Members des Vater-Dialoges ( zumindestens auf die Werte )....

Grüße

BOA

estartu

Das mit dem Zeiger mag eine schöne Lösung sein, aber so ganz entspricht auch sie nicht dem, was man in Büchern lernt:

Ein Dialog sollte einfach in einem neuen Projekt verwendet werden können.
Das ist aber nicht der Fall, wenn er die aufrufende Klasse kennen muss - es müsste sehr viel angepasst werden.

Daher ist es schöner, wenn man z.B. eine Recordsetreferenz und eine ID reingibt. Dann sind alle Daten da und der genaue Datensatz ist auch bekannt.
Muss man den Dialog weitergeben, braucht man nur seine beiden Dateien und die des Recordsets - und fertig.

BOA

estartu_de schrieb:

Das mit dem Zeiger mag eine schöne Lösung sein, aber so ganz entspricht auch sie nicht dem, was man in Büchern lernt:

Ein Dialog sollte einfach in einem neuen Projekt verwendet werden können.
Das ist aber nicht der Fall, wenn er die aufrufende Klasse kennen muss - es müsste sehr viel angepasst werden.

Daher ist es schöner, wenn man z.B. eine Recordsetreferenz und eine ID reingibt. Dann sind alle Daten da und der genaue Datensatz ist auch bekannt.
Muss man den Dialog weitergeben, braucht man nur seine beiden Dateien und die des Recordsets - und fertig.

Aloha,

deswegen schreibe ich ja, kommt auf den speziellen Fall an.
Liegen sie etwa als Member vor im aufrufenden Dialog ( in einer Liste z.B. ), oder liegen sie nur temporär in der aufrufenden Methode ?

Aber ganz ehrlich, gerade im Bereich Recordset, wo ich Daten aus einer DB optisch in einem Dialog anzeigen will, kannste diesen Dialog sowieso zu 90% in keinen anderen Projekt mehr benutzen, ohne anzupassen.
Und ob nun eine Zeile mehr ändern, ich glaube das macht es nicht fett.

Handelt es sich nur um temporäre Daten, die in der Dialog aufrufenden Methode existieren, funzt sowieso nur die direkte Datenübergabe im Konstruktor.

Grüße

BOA

estartu

Naja, ich hab an meinen Dialog gedacht, wo ich Postleitzahl/Ort auswählen kann. Den brauche ich allein innerhalb des Projektes andauernd. Eben bei jeder Adresseingabe.

ethereal

Meines Erachtens liegt darin ein großer Nachteil dieses MFC-Paradigmas. Zwar werden Pointer mitgeliefert (s. z.B. die Memberf. GetDocument(), SDI/MDI ), doch setzen diese voraus, dass die Members public sind. Was mich aber wirklich stört, ist, dass in vielen Lehrbüchern/Tuts dann auch tatsächlich gelehrt wird, einfach public-Members in die entsprechnenden Klassen einzufügen. Was haben die dann noch für einen Sinn? Da kann man dann gleich WinAPI in C schreiben, globale Variablen verwenden etc... (OK, das ist sehr überzogen, aber imo weist diese public-Unart bei MFC in eine ähnliche Richtung). Ich bin meist ganz gut gefahren, separate Klassen für die Datenverwaltung zu erstellen und nur das nötigste als public zu deklarieren. Nun besteht allerdings wieder ein Nachteil darin, ein Objekt solcher Klassen zu erzeugen, auf das dann mehrere MFCs zugreifen können, man kann sich also leicht im Kreis drehen.
Die Alternative von estartu_de bietet da immerhin einen besseren Ansatz, kann aber imo nicht das Ziel der MFC-Idee sein, wenn man die Members der Basisklassen (du erwähntest DoModal()) selbst definieren muß. Ebenso müsstest du dann DoModal für jede Dialogfeld-Klasse neu definieren, da du ja selten für jedes Dialogfeld die gleichen Parameter übergibst. Und wenn du dann die Daten vom Dialogfeld haben willst, musst du wieder die Members als public deklarieren. Meiner Meinung nacht ist das auch nicht optimal...

Einen konstruktiven Ausweg weiß ich leider auch nicht
Viele Grüße
E-the-Real