Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Detecting QDialog closure
Forum Update on Monday, May 27th 2025

Detecting QDialog closure

Scheduled Pinned Locked Moved Solved General and Desktop
5 Posts 2 Posters 2.5k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #1

    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-worxR 1 Reply Last reply
    0
    • JonBJ 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-worxR Offline
      raven-worxR Offline
      raven-worx
      Moderators
      wrote on last edited by
      #2

      @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

      --- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
      If you have a question please use the forum so others can benefit from the solution in the future

      JonBJ 1 Reply Last reply
      0
      • raven-worxR 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

        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by JonB
        #3

        @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-worxR 1 Reply Last reply
        0
        • JonBJ 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-worxR Offline
          raven-worxR Offline
          raven-worx
          Moderators
          wrote on last edited by raven-worx
          #4

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

          --- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
          If you have a question please use the forum so others can benefit from the solution in the future

          JonBJ 1 Reply Last reply
          2
          • raven-worxR 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.

            JonBJ Offline
            JonBJ Offline
            JonB
            wrote on last edited by JonB
            #5

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

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved