QAction still triggered when modal Dialog executed

ambershark

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.

stvokr

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?

stvokr

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.

SGaist

Hi,

Can you created a minimal sample application that shows this ?

ambershark

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.

stvokr

Here is a small sample application. I am using Qt 4.8.1 and Qt 5.2.1 on Windows 7.

mainwindow.h:
@#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QtGui>

class MainWindow : public QMainWindow
{
Q_OBJECT

public:
MainWindow(QWidget *parent = 0);
~MainWindow();

public slots:
void onActionTriggered();
};

#endif // MAINWINDOW_H
@

mainwindow.cpp:
@#include "mainwindow.h"

MainWindow::MainWindow(QWidget parent) :
QMainWindow(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() ) );

}

MainWindow::~MainWindow()
{
}

void MainWindow::onActionTriggered()
{
QDialog dialog( this );
dialog.exec();
}
@

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.

ambershark

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.

stvokr

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:
@void MainWindow::onActionTriggered()
{
QDialog dialog( this, Qt::Tool );
dialog.exec();
}@

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?

ambershark

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

I had possibly the same (or similar) issue, I also use QtDesigner, and I noticed it already adds the action to the help menu:

    menuHelp->addAction(actionManual);

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.