Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
JonB last edited by
I am unclear whether a subclass which overrides
QWidget::closeEvent()needs to conclude with something like
class JDialog(QDialog): def closeEvent(self, event: QtGui.QCloseEvent): myStuffToDoWhateverIrrelevant() # Do I *need* anything like next line? self.accept()
Looking at the http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-example.html#close-event-handler example, I understand why it needs to call
event->ignore();in the case where user does not want main window to close.
In my case I am not wanting to "handle" the closure event or in anyway affect it, I simply wish to do something of my own and then have it continue to do whatever it would or would have not done without my override.
The default implementation of this event handler accepts the close event.
Does that mean I am supposed to do that myself? Or maybe call the base class
In existing code I see overrides which do something but do not end with any kind of
event->accept()or base-class call or whatever. I don't know what is right.
Does that mean I am supposed to do that myself? Or maybe call the base class closeEvent() myself?
exactly, one of those 2 options.
It's good practice to basically call the base-class implementation if you do not consume an event
JonB last edited by JonB
Then for my new code I shall call then base class implementation. (I cannot call
ignoreetc., like I said I do not want to interfere in any way with whatever behaviour it had prior to my writing an override, I have no idea whether that ended up accepting etc.)
However, are you able to say what the existing/historical behaviour is where there are overrides but, after doing their own stuff, they do not accept/ignore/reject and do not call the base class? Is that undefined, is it default accept, does the base method not get called because of the override, or what?
However, are you able to say what the existing/historical behaviour is where there are overrides but, after doing their own stuff, they do not accept/ignore/reject and do not call the base class?
depends on the event type.
If you don't call the base class for most events your application might not behave as you want, unless you intentionally do not want to react on the event.
An not accepted event is passed to the next widget/parent (keyword "event propagation").
When an event is consumed (e.g. in the base class) it is accepted -> event propagation stops at this point, since a suitable receiver was found.
But events are basically not accepted by default.
JonB last edited by JonB
Thanks. I do understand about propagation. In this case (it's debugging stuff I am putting in) I am only interested in allowing a derived widget to "not interfere" in any way with whatever the base class widget would have done without my override having been defined at all, rather than anything to do with "next widget/parent", which is a different matter.
In any case, I have now put in a call to the base method everywhere in code where
closeEvent()is being overridden to be safe, and all seems to be working as it was.