Activate QWidget with a modal QDialog

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)
     {
         ......
     }
 });

Mephisky

@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 :-)

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

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 :-(

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.

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?

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?

Mephisky

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

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

THAT is my purpose. Could you give some suggestions?

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.

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?

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.

Mephisky

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

Mephisky

@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 :-)