xdn
9th April 2015, 14:56
Hi,
I just came across a widget with the following code in one of its methods (slightly paraphrased):
void MyWidget::showDialog()
{
Ui_Dialog dui;
QDialog dialog;
dui.setupUi(&dialog);
// some more stuff to setup dialog
dialog.show();
if (dialog.exec() == QDialog::Accepted)
{
// store dialog content somewhere
}
qDebug() << "END";
}
I'm rather surprised by the show() followed by an exec() which I've never seen before in this way.
What seems to happen is that the new dialog does not block the parent widget, because of the show().
I don't understand why a previous show() should have an impact on the behaviour of exec().
MyWidget remains responsive yet the rest of showDialog() does not get executed (no "END" is printed) until the dialog is closed (then it does get printed).
So basically the method seems to pause at the exec() yet MyWidget is responsive?!
Of course this leads to segmentation faults, if MyWidget gets closed before the dialog is closed.
If I comment out the show(), the exec() properly blocks and everything works pretty much as I would expect.
Is there any reason to use show() and exec() in this way (in any situation)?
Is it a wanted behaviour that a previous show() influences exec() in this way?
Isn't the correct way to open a dialog and remain responsive to connect a slot to the dialog's finished() method (and have the dialog be a member instead of a local variable)?
Best,
xdn
I just came across a widget with the following code in one of its methods (slightly paraphrased):
void MyWidget::showDialog()
{
Ui_Dialog dui;
QDialog dialog;
dui.setupUi(&dialog);
// some more stuff to setup dialog
dialog.show();
if (dialog.exec() == QDialog::Accepted)
{
// store dialog content somewhere
}
qDebug() << "END";
}
I'm rather surprised by the show() followed by an exec() which I've never seen before in this way.
What seems to happen is that the new dialog does not block the parent widget, because of the show().
I don't understand why a previous show() should have an impact on the behaviour of exec().
MyWidget remains responsive yet the rest of showDialog() does not get executed (no "END" is printed) until the dialog is closed (then it does get printed).
So basically the method seems to pause at the exec() yet MyWidget is responsive?!
Of course this leads to segmentation faults, if MyWidget gets closed before the dialog is closed.
If I comment out the show(), the exec() properly blocks and everything works pretty much as I would expect.
Is there any reason to use show() and exec() in this way (in any situation)?
Is it a wanted behaviour that a previous show() influences exec() in this way?
Isn't the correct way to open a dialog and remain responsive to connect a slot to the dialog's finished() method (and have the dialog be a member instead of a local variable)?
Best,
xdn