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

[Nikos Chantziaras]

I'm CCing the list.  That's what it's there for to begin with :-)

On 11/03/12 11:42, Adrien Guinet wrote:
> Le 10/03/2012 19:15, Nikos Chantziaras a écrit :
>> On 10/03/12 17:59, Thiago Macieira wrote:
>>> Please provide us a compileable testcase.
>>
>> I was able to reproduce this with a minimal application.  I'm attaching it.  It
>> just consists of minimal QApplication and QMainWindow subclasses.  The latter
>> overrides closeEvent() in order to pop-up a confirmation dialog that will
>> demonstrate the problem.  The former has a main() member function that is
>> invoked from the real main() function of the program using
>> MetaObject::invokeMethod().
>>
>> To reproduce the bug, run it from the terminal, and then try to close the
>> window.  You will notice that msgBox.exec() returns immediately.
>>
>> (Btw, this is on Gentoo Linux AMD64, using Qt 4.8.0.)
>>
>
> Hello,
>
> First, one remark : when deleting QObjects (as a QMainWindow), expect for some
> cases, always prefer using QObjet::deleteAfter. It will prevent some random
> crashes as this is the Qt main loop that will delete the object as soon as all
> events related to this object have been processed. See [1] for more information.
>
> Then, just some thoughts as I haven't time to test them :
>
>   * 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.  It 
doesn't even close it if you don't actually accept the event.  If you 
call ignore() on the passed event, then nothing happens.


>   * IIRC, there is a better way to "user-control" the exit of a QMainWindow.
> There is an example with the SDI/MDI models, in order to ask the user if he
> wants to save its modification. Maybe you can get inspiration from these examples.

The problem happens everywhere, not just in closeEvent().  I way to 
workaround the problem is to change this:

   void Application::main()
   {
       QFileDialog::getOpenFileName(0, "TEST", "", "All files (*)");
       this->fMainWin->show();
       while (true) {
           qApp->processEvents(QEventLoop::WaitForMoreEvents
                               | QEventLoop::AllEvents);
       }
   }

Into this:

   void Application::main()
   {
       this->fMainWin->show();
       QFileDialog::getOpenFileName(0, "TEST", "", "All files (*)");
       while (true) {
           qApp->processEvents(QEventLoop::WaitForMoreEvents
                               | QEventLoop::AllEvents);
       }
   }

That is, call show() on the main window before opening a file dialog. 
But still, this results in a visual glitch in the application where you 
have a window full of nothing showing up behind the file dialog.

The question here though is whether this actually is a real bug, in 
which case I should report it on the tracker, or is this expected behavior.