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. _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
