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. Activate QWidget with a modal QDialog
Forum Updated to NodeBB v4.3 + New Features

Activate QWidget with a modal QDialog

Scheduled Pinned Locked Moved Solved General and Desktop
12 Posts 3 Posters 1.3k 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.
  • M Offline
    M Offline
    Mephisky
    wrote on last edited by Mephisky
    #1

    Dear,
    My issue is, how to activate the QWidget with a running QDialog which is Qt::WindowModal.
    When dialog is exec(), I might go to another application, such as Chrome brower. Because dialog.exec() will block mouse and keyboard input, mouse clicking in the red area will not work. I want to know if there is an way to activate the widget by mouse clicking in the red. There is no need to raise the widget on the top of Chrome, just to inform me the widget is being blocked, such as raise or activate the dialog on the top.
    The code is like below:

     connect(ui->pushButton, &QPushButton::clicked, this, [] {
         MyDialog dialog;
         int iRet = dialog.exec();
         switch (iRet)
         {
             ......
         }
     });
    

    scr_230121.png

    Ronel_qtmasterR 1 Reply Last reply
    0
    • JonBJ JonB

      @Mephisky
      I do not understand. Are you saying showing a QFielDialog from your own code does give desired behaviour, i.e. you can still click on application window elsewhere brings your application up-front? Are you saying that Qt Creator, as an application, does allow same click when it is showing the "Open File" dialog?

      I don't know what Python has to do with Creator or anything else.

      M Offline
      M Offline
      Mephisky
      wrote on last edited by
      #12

      @JonB
      Dear, I've figured out the issue..
      It is the parameter parent in the constructor QDialog(QWidget *parent = nullptr, Qt::WindowFlags f = Qt::WindowFlags()) matters. I used it as nullptr. After passing the pointer of the main widget to QDialog, it behaviours as the same as my desire. However, it is true that the widget does not receive any events, such as QEvent::WindowActivate :-)

      1 Reply Last reply
      0
      • M Mephisky

        Dear,
        My issue is, how to activate the QWidget with a running QDialog which is Qt::WindowModal.
        When dialog is exec(), I might go to another application, such as Chrome brower. Because dialog.exec() will block mouse and keyboard input, mouse clicking in the red area will not work. I want to know if there is an way to activate the widget by mouse clicking in the red. There is no need to raise the widget on the top of Chrome, just to inform me the widget is being blocked, such as raise or activate the dialog on the top.
        The code is like below:

         connect(ui->pushButton, &QPushButton::clicked, this, [] {
             MyDialog dialog;
             int iRet = dialog.exec();
             switch (iRet)
             {
                 ......
             }
         });
        

        scr_230121.png

        Ronel_qtmasterR Offline
        Ronel_qtmasterR Offline
        Ronel_qtmaster
        wrote on last edited by
        #2

        @Mephisky Hi.You cannot activate it by mouse click because QDialog is always a top level widget.If you want to access it use a QWidget instead. According to the documentation:

        A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent's top-level widget (if it is not top-level itself). It will also share the parent's taskbar entry.

        So the best idea is to use a widget here

        M 1 Reply Last reply
        0
        • Ronel_qtmasterR Ronel_qtmaster

          @Mephisky Hi.You cannot activate it by mouse click because QDialog is always a top level widget.If you want to access it use a QWidget instead. According to the documentation:

          A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent's top-level widget (if it is not top-level itself). It will also share the parent's taskbar entry.

          So the best idea is to use a widget here

          M Offline
          M Offline
          Mephisky
          wrote on last edited by
          #3

          @Ronel_qtmaster
          Dear,
          When trying to use a QWidget instead of a QDialog, I am confused to keep the new widget staying on the top of main widget. Maybe I need some window flags? The Qt::WindowStaysOnTopHint can do that. However it make the widget on the global top of my windows desktop :-(

          JonBJ 1 Reply Last reply
          0
          • M Mephisky

            @Ronel_qtmaster
            Dear,
            When trying to use a QWidget instead of a QDialog, I am confused to keep the new widget staying on the top of main widget. Maybe I need some window flags? The Qt::WindowStaysOnTopHint can do that. However it make the widget on the global top of my windows desktop :-(

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

            @Mephisky
            When displaying a modal dialog, input/raising of other/parent window is disabled when clicking on it while modal dialog is shown. Your windowing system does this and controls behaviour deliberately. They way it works is standard for your windowing system, what the user is used to, and I don't see why you would want to or should alter this.

            If you really want to alter this behaviour: I don't know if there is a way to still recognise a click on a "blocked" window and do something. As I said, I just would not do this. Alternatively you could display the dialog as non-modal. But that means the user can actually interact with other windows, which you do not seem to want.

            M 1 Reply Last reply
            0
            • JonBJ JonB

              @Mephisky
              When displaying a modal dialog, input/raising of other/parent window is disabled when clicking on it while modal dialog is shown. Your windowing system does this and controls behaviour deliberately. They way it works is standard for your windowing system, what the user is used to, and I don't see why you would want to or should alter this.

              If you really want to alter this behaviour: I don't know if there is a way to still recognise a click on a "blocked" window and do something. As I said, I just would not do this. Alternatively you could display the dialog as non-modal. But that means the user can actually interact with other windows, which you do not seem to want.

              M Offline
              M Offline
              Mephisky
              wrote on last edited by
              #5

              @JonB
              Dear, except modal, so no way to set a widget to be always on the other one? Maybe raise widget2 in widget1::mousePressEvent() would work?

              JonBJ 1 Reply Last reply
              0
              • M Mephisky

                @JonB
                Dear, except modal, so no way to set a widget to be always on the other one? Maybe raise widget2 in widget1::mousePressEvent() would work?

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

                @Mephisky
                I believe that with a modal dialog showing your other window will not receive any input, such as a mouse press. That is the purpose of a modal dialog, to block input to anything but itself, else what is its purpose?

                You have not taken on board my point: your window manager decides how modal dialogs behave, whether other windows receive input, whether clicking on another window shows something or emits a beep to show it is currently blocked. I don't know why you want to change your window manager's behaviour.

                Try some other application which shows a modal dialog. For example, from Qt Creator select File > Open File or Project.... That should bring up the file selector dialog as modal? Now how does your window manager behave when you try to click to another window inside Creator?

                M 1 Reply Last reply
                1
                • JonBJ JonB

                  @Mephisky
                  I believe that with a modal dialog showing your other window will not receive any input, such as a mouse press. That is the purpose of a modal dialog, to block input to anything but itself, else what is its purpose?

                  You have not taken on board my point: your window manager decides how modal dialogs behave, whether other windows receive input, whether clicking on another window shows something or emits a beep to show it is currently blocked. I don't know why you want to change your window manager's behaviour.

                  Try some other application which shows a modal dialog. For example, from Qt Creator select File > Open File or Project.... That should bring up the file selector dialog as modal? Now how does your window manager behave when you try to click to another window inside Creator?

                  M Offline
                  M Offline
                  Mephisky
                  wrote on last edited by
                  #7

                  @JonB
                  Dear,
                  I know that you meant. Despite my top above, I find QT Creator behavior is what i need:

                  1. Open Qt Creator.
                  2. Select "Open File or Project", a dialog would show up.
                  3. Go to another program, such as chrome. At this moment Qt Creator is deactived.
                  4. Mouse click on the area inside Creator while outside of selector dialog.
                  5. Qt creator shows up and activates, with the dialog on the top.

                  THAT is my purpose. Could you give some suggestions?

                  JonBJ 1 Reply Last reply
                  0
                  • M Mephisky

                    @JonB
                    Dear,
                    I know that you meant. Despite my top above, I find QT Creator behavior is what i need:

                    1. Open Qt Creator.
                    2. Select "Open File or Project", a dialog would show up.
                    3. Go to another program, such as chrome. At this moment Qt Creator is deactived.
                    4. Mouse click on the area inside Creator while outside of selector dialog.
                    5. Qt creator shows up and activates, with the dialog on the top.

                    THAT is my purpose. Could you give some suggestions?

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

                    @Mephisky
                    You have never said what platform you are on. If your Creator behaves the way you describe --- up-front an application if you click on any of its windows when it is showing a modal dialog --- then I would expect your application to work the same way, as it's controlled by the window manager. I think you will find Creator, which is written with Qt, does not have any special code for handling this situation.

                    I suggest you try an application with a QFileDialog (possibly with and without DontUseNativeDialog) and see if you get the same behaviour as Creator.

                    M 1 Reply Last reply
                    0
                    • JonBJ JonB

                      @Mephisky
                      You have never said what platform you are on. If your Creator behaves the way you describe --- up-front an application if you click on any of its windows when it is showing a modal dialog --- then I would expect your application to work the same way, as it's controlled by the window manager. I think you will find Creator, which is written with Qt, does not have any special code for handling this situation.

                      I suggest you try an application with a QFileDialog (possibly with and without DontUseNativeDialog) and see if you get the same behaviour as Creator.

                      M Offline
                      M Offline
                      Mephisky
                      wrote on last edited by
                      #9

                      @JonB
                      Dear,
                      Thanks for your reply.
                      I use QT 5.15 + mingw 8.1.0, the target platform is Windows 11. I have tried both QFileDialog, with and without "DontUseNativeDialog", and it bahaviours the same with my requirements.
                      However, Qt Creator's code can be challenging, especially when it's written in Python. Could you provide some specific guidance on this?

                      JonBJ 1 Reply Last reply
                      0
                      • M Mephisky

                        @JonB
                        Dear,
                        Thanks for your reply.
                        I use QT 5.15 + mingw 8.1.0, the target platform is Windows 11. I have tried both QFileDialog, with and without "DontUseNativeDialog", and it bahaviours the same with my requirements.
                        However, Qt Creator's code can be challenging, especially when it's written in Python. Could you provide some specific guidance on this?

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

                        @Mephisky
                        I do not understand. Are you saying showing a QFielDialog from your own code does give desired behaviour, i.e. you can still click on application window elsewhere brings your application up-front? Are you saying that Qt Creator, as an application, does allow same click when it is showing the "Open File" dialog?

                        I don't know what Python has to do with Creator or anything else.

                        M 2 Replies Last reply
                        0
                        • JonBJ JonB

                          @Mephisky
                          I do not understand. Are you saying showing a QFielDialog from your own code does give desired behaviour, i.e. you can still click on application window elsewhere brings your application up-front? Are you saying that Qt Creator, as an application, does allow same click when it is showing the "Open File" dialog?

                          I don't know what Python has to do with Creator or anything else.

                          M Offline
                          M Offline
                          Mephisky
                          wrote on last edited by
                          #11

                          @JonB
                          Yes, Qt Creator and QFileDialog::getOpenFileName() does give me the expected behaviour.
                          I checked the source code of QFileDialog::getOpenFileName() , to confirm it is like dialog.exec().
                          I looked in to the code of Qt Creator, but I have no idea about where the code of Open File dialog of Qt Creator is, some codes is Python.

                          1 Reply Last reply
                          0
                          • JonBJ JonB

                            @Mephisky
                            I do not understand. Are you saying showing a QFielDialog from your own code does give desired behaviour, i.e. you can still click on application window elsewhere brings your application up-front? Are you saying that Qt Creator, as an application, does allow same click when it is showing the "Open File" dialog?

                            I don't know what Python has to do with Creator or anything else.

                            M Offline
                            M Offline
                            Mephisky
                            wrote on last edited by
                            #12

                            @JonB
                            Dear, I've figured out the issue..
                            It is the parameter parent in the constructor QDialog(QWidget *parent = nullptr, Qt::WindowFlags f = Qt::WindowFlags()) matters. I used it as nullptr. After passing the pointer of the main widget to QDialog, it behaviours as the same as my desire. However, it is true that the widget does not receive any events, such as QEvent::WindowActivate :-)

                            1 Reply Last reply
                            0
                            • M Mephisky has marked this topic as solved on

                            • Login

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