Solved Detecting QDialog closure
-
I wish to detect any & all places where a [modal]
QDialog
is closed, however that is achieved. (All my dialogs are derived from my ownJDialog(QDialog)
class, so I can override whatever I want there.)I had expected only to have to override/catch signal for a single method. However, I am finding I have had to override both
QDialog::done()
(for button close viaaccept
etc.) andQDialog::closeEvent()
(for dialog close via "X" button). This surprised me a bit, as I thought the former would invoke the latter, but it seems not.- Does this seem correct or am I missing something?
Further, if code somewhere does its own explicit
QDialog::close()
, I am trusting http://doc.qt.io/qt-5/qwidget.html#closeFirst it sends the widget a QCloseEvent.
to mean that my overridden
QDialog::closeEvent()
will still get hit.-
Again is that right?
-
Have I missed out any other ways of closing a dialog?
-
@JonB said in Detecting QDialog closure:
I wish to detect any & all places where a [modal] QDialog is closed, however that is achieved
so just listening to the close (or hide) event is sufficient
-
so just listening to the close (or hide) event is sufficient
Sorry, I do not understand what you have just written at all.
If by any chance you mean overriding
QDialog::close()
(actuallyQWidget::close()
) that does not get hit at all.If you mean overriding
QDialog::closeEvent()
, as I wrote above I find that is not hit (slightly to my surprise) when a button or whatever invokesDialog::accept
/reject()
, but only if the user closes the dialog via the "X" furniture.I'm sorry to be a pain, and I do appreciate your time, but could you kindly clarify precisely what you meant?
-
@JonB said in Detecting QDialog closure:
If by any chance you mean overriding QDialog::close() (actually QWidget::close()) that does not get hit at all.
close() is not virtual and thus not meant to be overridden.
i meant the closeEvent() yes.
I just checked the Qt code. Seems like accept()/reject() just hides the dialog, instead of "closing" it.So you can override hideEvent(). This one is called in all cases.
-
@raven-worx said in Detecting QDialog closure:
close() is not virtual and thus not meant to be overridden.
Ah ha! This is where PyQt/Python is depressing :(
When I sub-class a
QDialog
my editor (PyCharm) uses definitions to offer me everything I can override. This includesdef close(self):
in my derivedQDialog
, with a help tip of "Overrides method in QWidget", and it then shows my method overrides that one. Only now do I see the Qt docs:bool QWidget::close() [slot]
No mention of
virtual
.And it gets worse: everything can be overridden in Python, as there is no such thing as
virtual
(or anything else)! :( I don't quite get it, and I asked about this in Python a while ago, but I have a feeling that the way it works is: PyQt'sQWidget.close()
is actually a wrapper of some kind around C++/Qt'sQWidget::close()
. What it might be overriding with my code is effectively not the underlyingQWidget::close()
but rather only Python/PyQt'sQWidget.close()
wrapper. This all makes my brain ache.i meant the closeEvent() yes.
I just checked the Qt code. Seems like accept()/reject() just hides the dialog, instead of "closing" it.
So you can override hideEvent(). This one is called in all cases.Thanks, that at least confirms my findings. (Would have been nice if docs accept/reject/done had mentioned what you have discovered.) Because of the debugging nature of what I'm trying to do, I deliberately want to get at "closure" and not just "hidation"! At least I know where I'm at.
I'll struggle on with this. What I'm really trying to discover is when existing code "leaks" by failing to correctly release a dynamically created dialog. It's proving tricky to determine....