Solved Detecting QDialog closure

[JonB]

I wish to detect any & all places where a [modal] QDialog is closed, however that is achieved. (All my dialogs are derived from my own JDialog(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 via accept etc.) and QDialog::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#close

First 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?

[raven-worx]

@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

[JonB]

@raven-worx

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() (actually QWidget::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 invokes Dialog::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?

[raven-worx]

@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.

[JonB]

@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 includes def close(self): in my derived QDialog, 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's QWidget.close() is actually a wrapper of some kind around C++/Qt's QWidget::close(). What it might be overriding with my code is effectively not the underlying QWidget::close() but rather only Python/PyQt's QWidget.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....