I'm doing processEvent() just to make sure the dialog is painted before an heavy treatment. Basically it shows "Please wait" while the process is running. I guess I am not the only one doing such things... If I don't call processEvents on some platforms the dialog is just half painted, probably there are other ways to ensure it's painted (like updateGeometry() ) but until now that was working.
I want to show(), do something, and then delete the messagebox. Not just show() and return, what would be the point? I don't want to exec() because I don't want the user to need to click on something, it's just a waiting message that should not block the execution. It works fine on 521 whatever the platform, and it works fine on 530 except for mac, this alone should sound like regression imo. What I mean by lock: My application becomes non-responsive. I can see that the main thread is continuing, until it returns (if I don't call processEvent() ). Then nothing else happens, ever. Probably because the waitBox is modal, and is never deleted since it should be deleted by a deleteLater() that never occurs because the event loop is locked ;) Thanks for your patience Philippe Lelong Le 20-05-2014 21:13, Thiago Macieira a écrit : > Em ter 20 maio 2014, às 19:04:39, mai...@virtual-winds.org escreveu: >> Thanks for your reply >> >> Why is removing the processEvent the right thing to do? > > Because processEvents() means nested event loops. You shouldn't do > that. You > should show() and then return;, so the non-nested event loops resumes > executing. > > If you do need to blocking-show, then don't use show(), just use > exec(). > > I'm interested in knowing whether there's a lock up if you use any of > the > above solutions. And exactly what you mean by "lock". _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
