On Montag, 11. November 2013 19:42:13 CEST, Kevin Krammer wrote:
If anything, D-Bus, timer, whatever, causes deletion of the
dialog's parent,
in this case KMinesMainWindow, then it will delete its child QObject.
If a QObject with children on the stack gets deleted, you're in trouble anyway,
see the big fat warning in the QObject API about this.
When the C++ code of the functions cleans up the stack, it will
at least also
invoke the dialog's destructor.
This however would bite you if the deconstructor attempts to operate on the
deleted parent()
Long story short:
-----------------
if you cannot ressonably assume -or even better: guarantee- that the
environment is gonna survive the nested eventloop:
a) create the object with nested loop on the heap and assign it a qpointer
b) check whether the nested pointer is NULL after the nested loop has quit
c) if you need to perform more stuff on "this" after the nested loop has exited, assign a qpointer
to "this" before entering the loop and check it afterwards as well (for odds are good that
"this" has gone as well)
d) actually better guard any ("toplevel") pointers that you intend to access
after a nested event loop.
Alternatively under this (unsafe state) condition, just don't use a nested
eventloop.
Cheers,
Thomas
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
