QT Parent von Dialog (Speichermgmt)



  • Hi,

    wenn ich einen neuen Dialog erstelle, gehe ich davon aus, dass durch die Angabe eines Parents der Parent versucht diesen Dialog zu löschen, wenn er selbst gelöscht wird.

    Ist dies zunächst korrekt?

    Dann verstehe ich aber nicht ganz, wie ich es erreiche, dass ich einem Stackobjekt einem Parent gebe, ohne dass er versucht das zu löschen (wäre ja fatal). Ich will aber ein Parent übergeben, damit er z.B. automatisch das richtige Icon anzeigt - und in allen Subdialogen eben auch.

    Wie kriege ich das denn geregelt? Zurzeit helfe ich mir damit, dass ich als Parent eben doch wieder this angebe und die Dialoge dann eben über new anlege. Bis der Parentdialog zerstört wird, schwirren die Dialoge dann aber (durch accept/reject versteckt) im Speicher rum, oder?

    Danke schon Mal 🙂



  • Wenn der Dialog ein Stackobjekt und beendet ist, dann wird er auch weggeräumt und beim Parent ausgetragen. Somit sollte das kein Problem sein. Mache ich immer so 😉



  • Ggf. solltest du keinen NICHT MODALEN Dialog mit parent this (aufrufende Instanz) aufrufen, sondern mit dem ´darüber´ befindlichen Widget oder keinem. Wenn du nur Daten aus dem aufrufenden Widget brauchst, übergebe das nur dafür extra. Damit keine Dialog im Speicher rumschwirren, kann du angeben, das der Dialog sich nach Beendigung (close) selbst aus dem Speicher entfernt; siehe ´ ->setAttribute( Qt::WA_DeleteOnClose )´.
    Gruß Helmut



  • ScyllaIllciz:
    Woher weiß QObject denn, dass das ein Stackobjekt ist? Wird vom parent nicht stur delete child aufgerufen?

    Edit: Okay, einfach Mal Doku an der richtigen Stelle lesen beantwortet das: http://qt-project.org/doc/qt-4.8/qobject.html#dtor.QObject

    Also niemals ein parent als Stackobjekt übegeben, wie ich vermutet hatte.

    Das sollte aber bei z.B. QMessageBox::warning wohl nicht das Problem sein.

    Helmut.Jakoby:
    Super, vielen Dank 🙂

    QMessageBox::warning macht das vermutlich genau so, oder?



  • good to know



  • Eisflamme schrieb:

    Also niemals ein parent als Stackobjekt übegeben, wie ich vermutet hatte.

    Das muss jetzt nicht pauschal falsch sein. Sowas wär z.B. kein Problem:

    QMenu menu;
    QAction action("Beenden", &menu);
    menu.addAction(&action);
    

    Hier muss man den Parent zwar nicht übergeben, das ist aber auc nicht unbedingt ein Problem. Und bei vielen Klassen, die unbedingt einen QObject Zeiger haben wollen, kann man ruhig auch Stackobjekte reingeben. Man muss nur wissen, was man tut. Solang das parent als letztes stirbt, kann es problemlos auch auf dem Stack liegen.



  • Hm, aber wie stellt man denn sicher, dass das Parent als letztes stirbt?

    Und man übergibt dem Parent doch lediglich einen Zeiger auf das Stackobjekt. Wenn das Stackobjekt jetzt zerstört wird, weiß das doch der Parent nicht und führt dennoch delete aus oder nicht?



  • Meiner Meinung nach ist das ein Problem der Definition Stack Objekt. Ich hatte es so verstanden, dass wenn ich einen modalen Dialog habe, diesen auf dem Stack anlege einen Parent übergebe und wenn der Dialog geschlossen wird, er so vor dem Parent zerstört wird. Wie bei einer MessageBox eben. So sehe ich hier kein Problem und ich mache das immer so. Natürlich könnte es ein Member sein, dann darf man keinen Parent übergeben.



  • Eisflamme schrieb:

    Hm, aber wie stellt man denn sicher, dass das Parent als letztes stirbt?

    Und man übergibt dem Parent doch lediglich einen Zeiger auf das Stackobjekt. Wenn das Stackobjekt jetzt zerstört wird, weiß das doch der Parent nicht und führt dennoch delete aus oder nicht?

    Das kann man natürlich nur machen, wenn man das im Griff hat. z.B. in einer Funktion Objekte auf dem Stack anlegen, als Zeiger irgendwo reingeben, die entsprechenden Methoden kehren zurück und dann erst werden die Stackobjekte abgebaut. Wenn du aber einen Zeiger auf ein Stackobjekt an eine Methode weitergibst, die den Zeiger kopiert und er auch dann noch benutzt wird, wenn die Stackobjekte schon abgebaut sind, dann funktioniert es natürlich nicht. Aber das hat man ja im Griff und wenn man weiß, was die Methode damit macht, ist es kein Problem.
    Wenn ein QObject stirbt, sorgt der Destruktor dafür, dass sein Parent das mitbekommt und ihn aus seiner Liste entfernt.



  • Ahh, das hier:

    Wenn ein QObject stirbt, sorgt der Destruktor dafür, dass sein Parent das mitbekommt und ihn aus seiner Liste entfernt.

    wusste ich nicht. 🙂 Klar, dann geht's.


Anmelden zum Antworten