Overriding QWidget::closeEvent

[JonB]

I am unclear whether a subclass which overrides QWidget::closeEvent() needs to conclude with something like QCloseEvent::accept() or not?

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.

In http://doc.qt.io/qt-5/qcloseevent.html#details I note:

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 closeEvent() myself?

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.

[raven-worx]

@JonB said in Overriding QWidget::closeEvent:

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]

@raven-worx
Then for my new code I shall call then base class implementation. (I cannot call accept/ignore etc., 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?

[raven-worx]

@JonB said in Overriding QWidget::closeEvent:

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]

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