Qt-interest Archive, March 2008
Qt::WindowStaysOnTopHint still causes app exit in 4.3.4
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Constantin Makshin wrote:
> Well, the application really exits. But it's not a bug as I found this
> in QDialog code (in QDialog::setVisible() function):
> if (visible) {
> ...
> } else {
> ...
> // Reimplemented to exit a modal event loop when the dialog is hidden.
> QWidget::setVisible(visible);
> if (d->eventLoop)
> d->eventLoop->exit();
> }
>
> So it's still an intended behavior so your program works as expected.
I think we can argue that it does NOT work as expected. I don't think
anyone would *expect* the app to exit when the WindowStaysOnTopHint is
changed.
It's not a BUG, per-se, since the behavior is apparently INTENDED. But
not expected.
>
> On Fri, 07 Mar 2008 03:43:11 +0300, John Smith <invalid@xxxxxxxxxxx> wrote:
>> #include <QtGui>
>> #include "dialog.h"
>> Dialog::Dialog(QWidget *parent) : QDialog(parent), m_pButton(0)
>> {
>> setWindowTitle(tr("Sample dialog-based application"));
>> m_pButton = new QPushButton("Button", this);
>> connect(m_pButton, SIGNAL(clicked()), this, SLOT(onButton()));
>> }
>> void Dialog::onButton()
>> {
>> Qt::WindowFlags flags = this->windowFlags();
>> flags |= Qt::WindowStaysOnTopHint;
>> this->setWindowFlags(flags);
>> this->show();
>> return;
>> }
>
--
[ signature omitted ]
Message 17 in thread
I meant this behavior was expected by Qt developers, not by us. Just
because they made it to work that way. :)
However, the idea to close the window instead of hiding is very odd. I
can't find any good reason of doing that, so it'd be nice if somebody from
Qt development team told us why they made this decision.
On Fri, 07 Mar 2008 19:14:06 +0300, Paul Miller <paul@xxxxxxxxxx> wrote:
> Constantin Makshin wrote:
>> Well, the application really exits. But it's not a bug as I found this
>> in QDialog code (in QDialog::setVisible() function):
>> if (visible) {
>> ...
>> } else {
>> ...
>> // Reimplemented to exit a modal event loop when the dialog is
>> hidden.
>> QWidget::setVisible(visible);
>> if (d->eventLoop)
>> d->eventLoop->exit();
>> }
>> So it's still an intended behavior so your program works as expected.
>
> I think we can argue that it does NOT work as expected. I don't think
> anyone would *expect* the app to exit when the WindowStaysOnTopHint is
> changed.
>
> It's not a BUG, per-se, since the behavior is apparently INTENDED. But
> not expected.
>
>> On Fri, 07 Mar 2008 03:43:11 +0300, John Smith <invalid@xxxxxxxxxxx>
>> wrote:
>>> #include <QtGui>
>>> #include "dialog.h"
>>> Dialog::Dialog(QWidget *parent) : QDialog(parent), m_pButton(0)
>>> {
>>> setWindowTitle(tr("Sample dialog-based application"));
>>> m_pButton = new QPushButton("Button", this);
>>> connect(m_pButton, SIGNAL(clicked()), this, SLOT(onButton()));
>>> }
>>> void Dialog::onButton()
>>> {
>>> Qt::WindowFlags flags = this->windowFlags();
>>> flags |= Qt::WindowStaysOnTopHint;
>>> this->setWindowFlags(flags);
>>> this->show();
>>> return;
>>> }
--
[ signature omitted ]
Message 18 in thread
"Constantin Makshin" <dinosaur-rus@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:op.t7nlerycp27x8p@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Well, the application really exits. But it's not a bug as I found this in
QDialog code (in QDialog::setVisible() function):
if (visible) {
...
} else {
...
// Reimplemented to exit a modal event loop when the dialog is hidden.
QWidget::setVisible(visible);
if (d->eventLoop)
d->eventLoop->exit();
}
>So it's still an intended behavior so your program works as expected.
It is not the intended behavoir. The behavior I was expecting was that the
window would stay on top, not close and exit the application.
I did not close the window, or hide it, nor set visible to false. All I did
was change the flag to stay on top. I did not intend for the app to exit.
If this isn't a bug, then it is certainly a documentation error in the help
for Qt::WindowStaysOnTopHint.
--
[ signature omitted ]
Message 19 in thread
Documentation is almost correct.
There's a note in setWindowFlags() description saying it calls setParent()
internally. Documentation of setParent() function says it hides the window.
I said "almost correct" because I haven't found any notes about the fact
that hiding modal dialog windows actually closes it. Lack of such a small
note causes a lot of confusion...
I guess this behavior should be changed a bit, though. I've finally found
the reason of terminating dialog's event loop -- return control to its
parent (main window in most cases). But top-level dialogs should act as
any other top-level window and shouldn't close entire application on
hiding.
On Fri, 07 Mar 2008 20:37:22 +0300, John Smith <invalid@xxxxxxxxxxx> wrote:
> "Constantin Makshin" <dinosaur-rus@xxxxxxxxxxxxxxxxxxxxx> wrote in
> message
> news:op.t7nlerycp27x8p@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Well, the application really exits. But it's not a bug as I found this in
> QDialog code (in QDialog::setVisible() function):
> if (visible) {
> ...
> } else {
> ...
> // Reimplemented to exit a modal event loop when the dialog is
> hidden.
> QWidget::setVisible(visible);
> if (d->eventLoop)
> d->eventLoop->exit();
> }
>
>> So it's still an intended behavior so your program works as expected.
>
> It is not the intended behavoir. The behavior I was expecting was that
> the
> window would stay on top, not close and exit the application.
>
> I did not close the window, or hide it, nor set visible to false. All I
> did
> was change the flag to stay on top. I did not intend for the app to
> exit.
> If this isn't a bug, then it is certainly a documentation error in the
> help
> for Qt::WindowStaysOnTopHint.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 20 in thread
Hi,
> [...]
> main.cpp:
> [...]
> Dialog::Dialog(QWidget *parent) : QDialog(parent), m_pButton(0)
> [...]
The example is using a QDialog instead of a QWidget and launching the QDialog
event loop instead of the application event loop, which is new and important
information. Switching QApplication::exec() instead of QDialog::exec() fixes
the problem: the dialog stays on top and the application does not exit.
As pointed out by Constantin Makshin, a QDialog modal event loop is designed
to exit if the dialog is hidden:
http://doc.trolltech.com/4.3/qwidget.html#windowFlags-prop
Note: This function calls setParent() when changing the flags for
a window, and the side effects documented in setParent() also apply.
http://doc.trolltech.com/4.3/qwidget.html#setParent
Note: The widget becomes invisible as part of changing its parent,
even if it was previously visible. You must call show() to make the
widget visible again.
The documentation tries to make clear that a modal dialog event loop is tied
to its dialog. If it were not, the application could remain blocked. Since the
window associated to the dialog has been blocked and the dialog is hidden, in
some cases it might be impossible for a user to unblock the application. The
application would have to exit the event loop programmatically using a QTimer
for example:
http://doc.trolltech.com/4.3/qdialog.html#modal-dialogs
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.
I guess the documentation could indeed be improved a little bit here.
That said, is your real application lacking a QApplication loop? Does it only
have a modal dialog?
--
[ signature omitted ]
