I'm developing a Qt-based app, using QMainWindow class for the GUI. This app has a built-in server that listens for requests from my Chrome Browser extension, so that I may import information from current web-page into my Qt-app.
So when I press extension's button in the browser, it sends a signal to my Qt-app, which then pops up a QDialog so that I can add some additional information like tags, etc. When I close the QDialog, I expect to return to the browser, but instead my app's main window pops up into foreground if it wasn't minimized (if it was minimized, then it doesn't pop up).
How can I change this behavior, so that I return to my browser after closing QDialog, no matter if the app's main window was minimized or not? If that helps, when creating QDialog, I pass 0 as parent to it.
Related
So basically i have a class that inherits from QMainWindow and there's a toolbar action in my mainwindow that calls another small window where the user puts in some info, i want the mainwindow inaccessible i.e you shouldn't be able to click on it or interact with it unless you finish what you're doing on that small window or you close the small window. setWindowFlags(Qt::WindowStaysOnTopHint); only makes the small window be on top, but i can still access the MainWindow.
Looks like all i needed was the setWindowModality(Qt::ApplicationModal); method
Qt 5.12.6 MSVC2017 64-bit on Windows 10, Qt Creator 4.10.1.
I have a top level window derived from QMainWindow, which has a QMdiArea.
From the first main window I use a file open dialog to open a new document in a QMdiSubWindow and place it in the QMdiArea. After the file dialog returns but before I do the logic of opening the document, I have to call QApplication::setActiveWindow(this), to set it back to the main window, because the opening logic depends on the active window. The need for this somewhat appears related to https://www.qtcentre.org/threads/2950-ActiveWindow-changes-after-closing-QFileDialog in that the activeWindow becomes null, regardless of how I parent the file dialog.
I then open a second identical top level window and open another document using the same method.
What's very weird is that after the second QMdiSubWindow in the second QMainWindow is activated, the first QMainWindow gets activated again, and thus various follow-on operations affect the document in the first window rather than the second window which is the intended one. If I click back and forth on the main windows, the activation is correct.
If I create a new document directly from the second QMainWindow instead of using the file open dialog, then it works fine. The new QMdiSubWindow is created and shown in the second QMainWindow, without the first one getting activated. So this implicates the file dialog somehow.
When I put a breakpoint on a function triggered by the QMainWindow::activated signal, the stack trace shows this signal is coming from within Qt on its own accord, not from someplace in my code directly.
How can I find out why Qt is activating the first window when using the file dialog from the second window? At this point the code is too large to try to fit a minimal example here on SO.
--EDIT--
I added a one-shot QTimer at the end of the function that creates the QMdiSubWindow. Zero milliseconds after in creates the QMdiSubWindow it activates the first QMainWindow, then activates the current QMainWindow. That workaround seems to work, and the second QMainWindow becomes the active one. But only if I select away from it first. The fact that the hack works with 0 ms timer is also interesting. I'll be posting minimal example when I can.
thanks
Whats the difference between QDialog::show() and QDialog::open()?
show() will just show you the dialog without affecting the other windows in your program. open() will show() the window + prevent other windows from being accessible through setWindowModality(), i.e., it becomes a modal window.
This is useful if you want to open a file, for example, and you don't want the user to be able to do anything in the program until a file is chosen and that dialog is closed.
Quoting from Qt's manual:
A modal dialog is a dialog that blocks input to other visible windows in the same application. Dialogs that are used to request a file name from the user or that are used to set application preferences are usually modal. Dialogs can be application modal (the default) or window modal.
When an application modal dialog is opened, the user must finish interacting with the dialog and close it before they can access any other window in the application. Window modal dialogs only block access to the window associated with the dialog, allowing the user to continue to use other windows in an application.
The most common way to display a modal dialog is to call its exec() function. When the user closes the dialog, exec() will provide a useful return value. Typically, to get the dialog to close and return the appropriate value, we connect a default button, e.g. OK, to the accept() slot and a Cancel button to the reject() slot. Alternatively you can call the done() slot with Accepted or Rejected.
As it is stated in the doc, QDialog::open()
Shows the dialog as a window modal dialog, returning immediately.
whereas QDialog::show(), which is in fact QWidget::show(), will only show your dialog as a standard, non-modal widget.
I am trying to implement a terminal in my application.
Currently, class Terminal inherits from QMainWindow, and all of its contents are lost if the close button is triggered. This does not affect the main application though.
I want the contents to stay and be accessible by the rest of the application. How can I achieve that?
I have a QDialog which i'd like to be modal, i.e. I'd like the user to be locked out of the GUI completely until I programatically hide the dialog.
Here is a small reproducible example:
QDialog *dialog = new QDialog(this, Qt::Splashscreen);
dialog->setModal(true);
dialog->setWindowModality(Qt::ApplicationModal);
dialog->exec();
This is easily closed by clicking outside of the dialog.
Pressing the esc key would also close the dialog however in my custom implementation I am catching the event and dealing with it separately.
Edits
This only seems to occur on Windows, on Linux it behaves as desired.
Pressing alt + F4also closes the dialog regardless of catching key events.