[Interest] QNetwork classes for submitting google forms
Thiago Macieira
thiago.macieira at intel.com
Mon Jun 14 17:07:53 CEST 2021
On Sunday, 13 June 2021 12:23:58 PDT Max Paperno wrote:
> Huh? In the source code somewhere it says "don't use processEvents()?"
> Seems maybe that belongs in the docs... I understand what it means
> to read the source to see how something works, but I'm not sure how that
> applies here.
I said it *is* the source code, not "in the source code". You have to
interpret what it does and also what it does not do.
> > QEventLoop calls processEvents for you, but it also reacts to quit() and
> > other event-interruption mechanisms, as well as interrupt-prevention
> > mechanisms. If you call processEvents() on your own, you have to provide
> > your own mechanism. Many an application got stuck calling processEvents()
> > after being asked to exit that loop.
> >
> > If you think you need to exclude UI events, you're wrong.
> >
> > If you think you want to process a limited number of events (especially
> > "just one"), you're wrong.
>
> Thanks for elaborating. So the actual answer/advice is to use
> processEvents() _correctly_ (or QEventLoop which "autmagically" does the
> "right thing" for you... read its the code to see what that is). Which
> is certainly a valid point. I will amend any future mention if it with
> a big *"when used correctly" footnote instead of assuming that someone
> would already do that in the first place.
The actual advice is to not nest event loops. Return to the outer event loop
(assuming it is started, of course). This applies to modal dialogues too:
show() and return to the event loop.
If you have to start a new event loop level, then use the exec() functions in
QCoreApplication, QThread or QEventLoop.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Interest
mailing list