[Interest] Strange problem where exec() of dialogs returns immediately
realnc at gmail.com
Sun Mar 11 17:25:58 CET 2012
On 11/03/12 17:51, Thiago Macieira wrote:
> On domingo, 11 de março de 2012 16.31.34, Nikos Chantziaras wrote:
>>> * the issue I think is that you try to create a new QMessageBox in
>>> thus while the parent object is being deleted. Try to set a NULL parent
>>> object to this message box (just to try)
>> Nah, doesn't help. closeEvent() does not delete the widget anyway.
> But it is the creation of that message box that causes the problem, right? Try
> removing the message box and you'll see it works again.
Of course if I remove the message box the bug doesn't trigger, because
the point of this is that exec() returns immediately. If I remove the
message box, there's no call to exec().
I'm reporting a problem with exec(), not the absence of one when not
using exec() :-)
Note that I chose to demonstrate the problem inside of closeEvent() in
order to avoid introducing more code (for example a button or a menu
option that would pop-up a dialog). For example, I could introduce a
QPushButton that when pressed calls a slot which then opens a message
box. The problem would still be there. Using closeEvent() though just
allows for a shorter minimal example.
> Also, does the problem
> go away if you don't show that file dialog?
Yes, without the file dialog, the problem disappears. It doesn't matter
though whether the dialog is native or not (I can pass
QFileDialog::DontUseNativeDialog and it still happens.)
> Do you need the Application class?
> I repeat what I said in the previous email: remove EVERYTHING that doesn't
> cause the problem to disappear.
> You should be able to make this problem with just one .cpp.
If I remove the Application class and move Application::main() to
MainWindow::main(), the problem goes away. So this is the most minimal
code I could come up with that still triggers it.
More information about the Interest