[Interest] Strange problem where exec() of dialogs returns immediately

[Nikos Chantziaras]

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
>>> closeEvent,>
>>> 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.