Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QAction still triggered when modal Dialog executed
I noticed that a QAction of a MainWindow is still triggered via shortcut when a modal dialog is shown in front of the mainwindow. When this action opens the dialog, the dialog will be executed twice.
// dialog triggered via shortcut
QDialog myDialog( this );
myDialog.setModal( true );
This problem occurs only when I create a new Dialog like shown above. If I use a member instead the dialog wont be shown twice but it will be still executed twice because the action is still triggered.
// dialog triggered via shortcut
if( !m_dialog )
m_dialog = new myDialog( this );
myDialog->setModal( true ); myDialog->exec();
Is this a normal behavior that actions of the mainwindow are still triggered through modal dialogs?
No it is not normal. I would guess your action isn't parented right so it wasn't disabled by the dialog's modality.
From the docs, "The window is modal to a single window hierarchy and blocks input to its parent window, all grandparent windows, and all siblings of its parent and grandparent windows."
My actions on my menubars and toolbars are definitely disabled when a modal dialog is executed. This is in linux using KDE, pretty sure last time I tested it in windows and osx both blocked the input as well.
I defined the action via QtDesigner within the ui file. It is defined in ui_mainwindow.cpp as
@actionSettings = new QAction(MainWindow);@
I think this is correct. Any other ideas?
Btw, I have a menubar and a toolbar in my program, and all menus are disabled while executing the modal dialog. But the actions in the toolbar are still enabled.
I observed this phenomenon in many of my applications.
Can you created a minimal sample application that shows this ?
The action looks right but there is still something definitely wrong. It is weird the toolbar stuff is enabled. It shouldn't be but maybe there is a parenting issue with the toolbar.
My toolbar and menubar share the same actions (as they should) and those actions are disabled during the modal dialog's exec() call. Even hotkeys don't activate them.
What operating system and version of Qt are you using? And a minimal example like SGaist requested would be great to test with.
Here is a small sample application. I am using Qt 4.8.1 and Qt 5.2.1 on Windows 7.
class MainWindow : public QMainWindow
MainWindow(QWidget *parent = 0);
#endif // MAINWINDOW_H
MainWindow::MainWindow(QWidget parent) :
QToolBar toolBar = new QToolBar( this );
addToolBar( Qt::TopToolBarArea, toolBar );
QMenuBar* menuBar = new QMenuBar( this ); QMenu* menu = new QMenu( menuBar ); menu->setTitle( "Show" ); menuBar->addAction( menu->menuAction() ); setMenuBar( menuBar ); QAction* action = new QAction( this ); action->setText( "Show Dialog" ); action->setShortcut( QKeySequence( "Ctrl+T" ) ); toolBar->addAction( action ); menu->addAction( action ); connect( action, SIGNAL( triggered() ), this, SLOT( onActionTriggered() ) );
QDialog dialog( this );
The QAction problem, that the action is not disabled when the modal dialog is shown, is the same.
But my main problem that I can trigger the action again when the dialog is shown is no problem in that sample.
I think I have to review my code.
Yea it definitely sounds like you have some parenting issues. That is why it can't disable everything properly. If you don't want to change parents of things in your code you can always disable the stuff manually.
I found the problem. It is not a parenting problem.
The difference to the example above is that I used a derived class of QDialog and initialized it with the Qt::Tool flag.
Accordingly the example above would be:
QDialog dialog( this, Qt::Tool );
I don't know the specifications of Qt::Tool Dialog, but I think as a modal dialog it should also block shortcuts of mainwindow actions. But is does not. This occurs in Qt 4.8.1 as in Qt 5.2.1.
Is this maybe a bug?
Well tool widgets aren't the same as toolbars so I could understand there being different action disabling stuff going on.
Whether it should or should not keep actions active during a modal dialog I can't say. I could see a situation in my mind where I would like both behaviors. Maybe the Qt devs just made a decision and went with it.
jtg14 last edited by
I had possibly the same (or similar) issue, I also use QtDesigner, and I noticed it already adds the action to the help menu:
In addition, (before I realized this) I was also manually connect()ing the trigger() QAction signal to a slot in my application, so when I clicked Help -> Manual, the slot was being executed twice.
Once I removed my manual call to connect(), the trigger() signal was only being delivered once and my bug was fixed.