4. MFC Funktionen und Klassen vom Mutterdialog ins Tochterdialog übernehmen

MFC Funktionen und Klassen vom Mutterdialog ins Tochterdialog übernehmen

  • C

    Du mußt deinen jeweiligen Tochter-Dialogen einen Zeiger auf den Mutterdialog mitgeben (z.B. beim Ctor-Aufruf oder als globale Variable), dann kannst du über diesen Zeiger auf Methoden des MuDlg zugreifen.

    0
  • A

    Wenn im Tochterdialog die gleichen Funktionen wie im Mutterdialog benötigt werden, dann sollten beide Dialoge doch von einer eigens geschriebenen Dialogklasse abgeleitet werden, oder versteh ich da was falsch? Somit hat man in beiden schon mal die gleiche Funktionalität. Was die Variablen/Daten angehet, so würde ich das auch mit einem Zeiger auf den jeweils anderen Dialog machen. Aber vielleicht hab ich das ja auch alles falsch verstanden....

    0
  • D

    @ AndyDD
    Du hast das vollkommen richtig verstanden.
    Aber wie leite ich beide von einer eigens geschriebenen Dialogklasse ab.
    Daran hab ich auch schon in etwa gedacht. Weis bloß nicht wie ich das realisieren soll. 😞
    Thx
    Gruß dArIcO

    0
  • A

    dArIcO schrieb:

    @ AndyDD
    Du hast das vollkommen richtig verstanden.
    Aber wie leite ich beide von einer eigens geschriebenen Dialogklasse ab.
    Daran hab ich auch schon in etwa gedacht. Weis bloß nicht wie ich das realisieren soll. 😞
    Thx
    Gruß dArIcO

    Wie jetzt? Du erstellst Dir einfach eine Klasse, die von der Klasse CDialog oder CHTMLDialog abgeleitet ist. Bei Visual C++ 6.0 geht das mit dem Klassenassistenten bei der Version 2003 in der Klassenansicht (Rechtsklick->Hinzufügen->Klasse hinzufügen). Dieser Klasse (z.B. CMeineDialogklasse) gibst Du die Funktionalität in Form von Memberfunktionen und Membervariablen.
    Irgendwo in der Anwendung werden dann Mutter- und Tocherdialog gebracht. In der entsprechenden cpp-Datei includierst Du die Header-Datei Deiner selbstgeschriebenen Klasse. Danach müssen nur noch zwei Instanzen erzeugt werden, die dann die gleichen Funktionalitäten haben.

    #include "MeineDialogklasse.h"

....

CMeineDialogklasse   Mutterdialog;
CMeineDialogklasse   Tochterdialog;
    0
  • D

    OK, hab das nun mal probiert, aber wie es aussieht bring ich es nicht auf die Reihe. Gibt es da noch eine andere Methode? 😕

    0
  • U

    nene.
    Bei CAsyncSockets wird der Dialog informiert der in der abgeleitete Klasse von CAsyncSocket defniert ist.
    Wenn du nun deinen 2ten Dialog DoMOdal aufrufst dann ist dieser eben Modal.
    Dh dein Hauptdialog emfängt keine Nachrichten von CAsyncSocket.

    Wenn du nur auf Funktionen deinen Hauptdialogs zugreife willst dann kannst du diese Funktionen auf in eine eigene Klasse schreiben.
    Willst du das nicht dann übergebe deinem 2ten Dialog den this des Hauptdialogs und du kannst auf alle publicfunktionen und Variablen zugreifen.
    Sehe aber derzeit keine Sinn darin Socketfunktionen in beiden Dialogen zu haben.

    0
  • P

    Hallo,
    ich habs mal so probiert:

    in der Hauptklasse das Child Dialog aufrufen, z.B. in einer Fuktion der Hauptkl.
    so:

    void CMainDlg::CallChild()
{
    CChildDlg* pDlg = new ChildDlg();
    pDlg->DoModal(); // jetzt ist das Kindsdialog angezeigt!? für das aufräumen mußt du auch sorgen
}

// jetzt in der Childklasse in der header datei:

class CChild:public CDialog
{
public:
    CMainDlg* pMainDlg;
    // und weiter eine Funktion die die Funktion des Hauptdialogs aufruft:
    void CallMainDlgFunctions();
    // usw...

}
    // in der ChildDlg.cpp wird dann die Funktion aufgerufen die das Haupt Dialog anspricht:

void CChildDlg::CallMainDlgFunctions()
{
    // jetzt kann ich die Fuktionen des Hauptdialogs benutzen
    pMainDlg->MainDlgFunction();

}

    das einzige problem das ich gehabt habe ist das ich nicht auf die private und protected methoden
    zugreifen konnte!

    ich denke mal das es das ist was du gemeint hast??? 😕

    grüsse
    pixel

    0
  • P

    P.S. ich weis jetzt nicht ob ein modales Dialog das beste ist da das hauptdialog
    sonst im hintergrund ist solange du das kindsdialog geöffnet hast?! 😕

    0
  • A

    Unix-Tom schrieb:

    nene.
    Bei CAsyncSockets wird der Dialog informiert der in der abgeleitete Klasse von CAsyncSocket defniert ist.
    Wenn du nun deinen 2ten Dialog DoMOdal aufrufst dann ist dieser eben Modal.
    Dh dein Hauptdialog emfängt keine Nachrichten von CAsyncSocket.

    Wenn du nur auf Funktionen deinen Hauptdialogs zugreife willst dann kannst du diese Funktionen auf in eine eigene Klasse schreiben.
    Willst du das nicht dann übergebe deinem 2ten Dialog den this des Hauptdialogs und du kannst auf alle publicfunktionen und Variablen zugreifen.
    Sehe aber derzeit keine Sinn darin Socketfunktionen in beiden Dialogen zu haben.

    Sorry, das hatte ich ganz vergessen. Kann man das mit den Sockets nicht in das Doc legen, also quasi zentral für beide Dialoge behandeln? Ich hab keine Ahnung davon, damit hab ich mich noch nie beschäftigen dürfen.

    @pixel: Ich seh ebenfalls ein Problem mit modalen Dialogen. Spricht was dagegen die nichtmodal (also mittels Create()) zu machen?

    0
  • P

    Hi,
    ein nichtmodales ist eigendlich die richtige lösung, wenn du schon ein chat programmierst, sollen user in der lage sein zwischen den fenstern zu wechseln,
    denk an andere chat programme, wenn zum beispiel eine private nachricht erhalten wird öffnet sich ein kleines fenster, das hauptfenster dagegen ist noch da und auch verfügbar, ich meine, du kannst switchen zwischen diesen zwei und in beide nachrichten schreiben!?

    lg
    pixel

    0
  • U

    Wenn du eine Dialoganwendung hast dann hast du kein DOC/VIEW.
    Ich würde dir aber auch empfehlen dich zuerst mit Klassen u beschäftigen bevor du mit SDI/MDI hantierst.
    Das ist dann noch komplexer.

    Aber klar: Sockets gehören dann nicht in die View bei SDI/MDI.

    0
  • A

    Unix-Tom schrieb:

    Wenn du eine Dialoganwendung hast dann hast du kein DOC/VIEW.
    Ich würde dir aber auch empfehlen dich zuerst mit Klassen u beschäftigen bevor du mit SDI/MDI hantierst.
    Das ist dann noch komplexer.

    Aber klar: Sockets gehören dann nicht in die View bei SDI/MDI.

    Ok, dann lag ich mit meinem Vorschlag nicht unbedingt falsch. Ob er nun eine dialogfeldbasierende Anwendung verwendet hat ist nicht unbedingt ersichtlich. Aber konnte man nicht auch bei irgendeiner Version die Unterstützung Doc/View für Dialoganwendungen aktivieren? Is nur mal so eine Frage...

    0
  • D

    ich hab das ganze jetzt mal Nicht-Modal gemacht:

    CDialog* pDlg;

pDlg = new CDialog; 

pDlg->Create(IDD_DATEISENDEN,this); 

pDlg->ShowWindow(SW_SHOW); 
delete pDlg;

    Das ganze funktioniert auch ohne Fehler, jedoch wenn ich auf den Button klicke damit das ChildDlg geöffnet werden soll, dann blinkt [.wie aktualisiert.] das MuDlg auf, und mehr nicht. Woran liegt das?
    Erstmal dickes Thx an alle für eure Antworten!
    Gruß dArIcO

    0
  • U

    wenn du den dialog sofort wieder löscht ist es kein wunder das er gelöscht (geschlossen) wird.
    erstellen die instanz nicht in einer funktion den wenn die funktion verlassen wird dann existiert gem. den c++-regeln auch die dialogklasse nicht bzw. kann es auch zu memleaks kommen wenn du delete nicht aufrufen würdest.

    0
  • D

    ne andersrum: das childdlg wird kurz geöffnet geht aber sofort wieder zu. hab das ganze mal versuct zu unterdrücken, geht auch nicht

    0
  • U

    Ließ mal bitte was ich geschrieben habe:
    CDialog* pDlg;

    pDlg = new CDialog; //Instanz wir erzeugt

    pDlg->Create(IDD_DATEISENDEN,this);

    pDlg->ShowWindow(SW_SHOW); // Dialog wird angezeigt
    delete pDlg; // Dialog wird beendet

    Alles klar!!

    0
  • D

    Jetzt habe ich es!
    Das ChildDlg öffne ich Nicht-Modal. Habe eine eigene Klassen geschrieben, worauf dann alle zugreifen können.
    Aber nochmals danke an alle die ihren Beitrag dazu gegeben haben!
    Gruß dArIcO

    0
Anmelden zum Antworten