[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