In my case, we're creating a kind of progress window. The code that runs while the dialog is up is rather old and not thread-safe. But using Qt before 5.3 I can show the dialog, run the computation, adjust the information in the dialog and call processEvents to cause it to repaint and to allow the user to click an Abort button. When the computation is finished, I call exec() to wait for the user to click the OK button.
With the recent changes, calling processEvents() causes the modal session to start, blocking any further execution outside the dialog's event loop. This is how QProgressDialog works. From the QProgressDialog documentation of setValue(): Warning: If the progress dialog is modal (see QProgressDialog::QProgressDialog()), setValue() callsQApplication::processEvents(), so take care that this does not cause undesirable re-entrancy in your code. For example, don't use a QProgressDialog inside a paintEvent()! -John Weeks On May 20, 2014, at 12:13 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > 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". > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
