Expected behavior of Qt::Tool style?

[Valistar]

Hello,

I'm looking at an application bug where on Windows, opening a dialogue causes the program to disappear from the alt-tab menu (though not the taskbar). This seems to be a result of the Qt::Tool flag + WS_EX_TOOLWINDOW style being applied to the dialog widget.
The widget hierarchy is QMainWindow->QDialog. Is it expected that applying this flag to a child seems to effect the parent, as far as how Windows handles it? I'd assume this would just prevent this dialog window from showing up in these places. Or am I missing something, or is something tragically wrong with the code/app somewhere?

I tried changing the hierarchy to QMainWindow->QWidget(central widget)->QDialog, with no effect. Making the QDialog a sibling, or removing the Qt::Tool flag does fix the alt-tab issue but is undesirable behavior.

Seemingly relevant snippets:



MainWin::MainWin(QWidget *parent)
: QMainWindow(parent)
{
ui.setupUi(this);
...
}

void MainWin::doClick()
{

QScopedPointer<Poppy> theBox(new Poppy(this));
theBox->setModal(true);
theBox->setWindowState(Qt::WindowActive);
theBox->exec();
}

Poppy::Poppy(QWidget *parent)
: QDialog(parent)
{
ui.setupUi(this);
this->setWindowFlags(Qt::Tool);
this->setModal(true);
ui.validationWarning->hide();
// connect slots to signals
...
}

[yeye_olive]

What happens if you pass Qt::Tool directly to the QDialog constructor (i.e. QDialog(parent, Qt::Tool)) instead of setting it after construction?

I do not remember seeing a modal tool window in any GUI. Maybe this unusual pattern was not considered or tested in Qt.

On a side note, instead of QScopedPointer<Poppy> theBox(new Poppy(this)); you could simply allocate the Poppy on the stack (assuming you do want a modal dialog).

[Valistar]

Setting it in the constructor does fix it, though it causes the dialog window to be hidden after alt-tabbing. I've seen other threads about that though, with some resolutions. Also, I'll look into your other suggestions after work and see if there's an overall better solution for this widget.

Out of curiosity without digging into internals, do you know why setting it in the parent constructor would matter? I'd expect a setter and a constructor to have the same end-result.

Thanks.

[yeye_olive]

Out of curiosity without digging into internals, do you know why setting it in the parent constructor would matter? I'd expect a setter and a constructor to have the same end-result.
I do not know about the internals either, and only relied on what I could find in the documentation, which I find to be somewhat lacking on this particular topic. For instance, the flags passed to the QDialog constructor default to 0, but the documentation states that the non-zero Qt::Dialog flag is on for QDialog by default. This leads me to suspect that the QDialog constructor adds some (unspecified) flags on its own, and that subsequently calling QWidget::setWindowFlags() may clear them. Maybe passing Qt::Tool to the constructor is actually equivalent to calling dialog->setWindowFlags(dialog->windowFlags() | Qt::Tool) afterwards, but this is a mere conjecture.

Secondly, QWidget::setWindowFlags() warns about setParent() being called, and I admit being suspicious of the effects that might have on a QDialog (whose documentation mentions the Qt::Dialog flag being cleared on that occasion).