Verstuurd vanaf mijn iPhone
> Op 7 aug. 2016 om 09:12 heeft Frederic Marchal > <frederic.marc...@wowtechnology.com> het volgende geschreven: > > On Thursday 04 August 2016 11:20:58 Thiago Macieira wrote: > > On quinta-feira, 4 de agosto de 2016 10:32:26 PDT John Weeks wrote: > > > > On Aug 4, 2016, at 10:04 AM, Thiago Macieira <thiago.macie...@intel.com> > > > > wrote: > > > > > > > > Starting an event loop from inside another event loop. > > > > > > > > exec() → some slot or event handler → exec() > > > > > > It would also seem to cover any use of QDialog::exec() in the main thread, > > > and QDialog can be used only in the main thread. > > > > Correct. Don't use exec(). Call show() it and return to the existing > > mainloop. > > That's very restrictive! > > It is common (at least to me) to call QFileDialog::getOpenFileName() when the > user clicks on the "Open" menu and then use the returned file name to carry > on the open action. QFileDialog::getOpenFileName() does call QDialog::exec(). > According to you, it must be avoided like the plague… It means it renders > similar QFileDialog static methods useless. > > Yet, I don't see where the problem is. QDialog::exec() displays a modal > dialog. It is not possible to click again on the menu or button that > displayed the dialog in the first place. It effectively breaks recursive > looping, right? > Wrong. There are many sources of events, and only the ones related to user input are blocked this way. André > Frederic > > _______________________________________________ > 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