[Interest] Relationship between a QEventLoop and QCoreApplication::exec().

Frederic Marchal frederic.marchal at wowtechnology.com
Sun Aug 7 09:12:18 CEST 2016


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.macieira at 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?

Frederic

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160807/a0774e5d/attachment.html>


More information about the Interest mailing list