E
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
