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. How to detect that a Qdialog has been closed
QtWS25 Last Chance

How to detect that a Qdialog has been closed

Scheduled Pinned Locked Moved General and Desktop
6 Posts 5 Posters 11.7k 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.
  • V Offline
    V Offline
    vitorino
    wrote on last edited by
    #1

    Hi, How can I detect in the MainWindow that a Qdialog has been closed. Could someone explain it to me with code? Thanks a lot.

    1 Reply Last reply
    0
    • C Offline
      C Offline
      ckakman
      wrote on last edited by
      #2

      Hi,

      QDialog "documentation":http://doc.qt.io/qt-5/qdialog.html#details has some code examples.

      If you use a model dialog, QDialog::exec() blocks the UI thread and returns a value.

      If you use nonmodel dialog, you can connect a slot to the finished() signal of QDialog.

      1 Reply Last reply
      0
      • jerome_isAviableJ Offline
        jerome_isAviableJ Offline
        jerome_isAviable
        wrote on last edited by
        #3

        for exemple, if you have a dialogbox who need some arguments from caller... in the exemple, the dialogbox class is "mydialogBox" and want an argument.
        modal mode:

        @
        mydialogBox dial(this, my_argument);
        int result = dial.exec(); // this is a modal call
        if(result==QDialog::Accepted) {
        // here i can do something when the dialogbox close by an "accept()" signa
        QString the_data, an_other_one;
        the_data = dial.my_public_data;
        an_other_one = dial.my_public_function_get_qstring_data();
        // etc...
        }
        else {
        //here, i hang if dialogbox has been close by "reject() signal (like a cancel)
        .....
        }
        @
        for non modal mode, when a signal (who could be same accept() ot reject()) indicate the dialogbox close, you need to link it with a connection from the slected signal to a slot.
        (non modal would be if you call the dialogbox by "show()" )

        1 Reply Last reply
        0
        • A Offline
          A Offline
          andre
          wrote on last edited by
          #4

          Apart from the two modes identified by ckakman, there is a third one. A modal dialog box does not need to be opened by using exec(). Instead, it can also be opened using open(). This will also make the dialog modal, but code execution will continue and no local eventloop will be started. You will need to use signals and slots as in the non-modal case.

          For modal dialogs, I'd suggest to prefer the open() method. If you have Qt5 and c++/11 at your disposal, it is not that more complicated to design, but it has the benefit of not exibiting any of the suprises of nested eventloops (which can lead to crashes and strange unforseen resursions and even effects that look a lot like the issues you can have with multi-threading).

          If you don't have Qt5 and c++/11, then it means that your code gets spread over more than one method: the method creating the dialog, and the method or methods handling its result. Otherwise, you can use lambda's for that, which keeps your code concentrated in one location.

          1 Reply Last reply
          0
          • jerome_isAviableJ Offline
            jerome_isAviableJ Offline
            jerome_isAviable
            wrote on last edited by
            #5

            Andre, thanks for great explication, but, could you also please give us an exemple of little code for show how works this third method (and maybe give it a name) ?

            i have some problem with strange crash application at call or close time of dialogbox sometimes... also, i can see a crash from QSql drivers... but i don't know, you suggest this call is a bad practice around exec() (who is an exemple from qt itself as you can read here: http://doc.qt.io/qt-5/qdialog.html#details). You not tell clearly it is bad, but you tell this can make some bad surprises of "nested event loops (which can lead to crashes...". I consider that a code who produce crashes is a bad practice.

            i hope your way could be a solution for me with maybe what you talk about this "wrong" exemple from qt usual .exec() call of modal dialogBox.

            thanks for your help and teach (i hope also than someone from Qt will read and change exemples in the doc... loose time to read a doc and write bad code exemple provide by the doc is so untoward).

            1 Reply Last reply
            0
            • V Offline
              V Offline
              voodoo
              wrote on last edited by
              #6

              Maybe the easiest way is check/act within the implemented destructor after inheriting QDialog class. You can emit signal from there or do whatever you want to do.
              Be aware of memory management!

              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