[Qt-interest] Controlling when timers run

william.crocker at analog.com william.crocker at analog.com
Sun Jan 17 17:15:07 CET 2010


>> The problem here is that many apparently innocuous activities
>> process events as a side effect. I believe the following are
>> examples:
>>
>>     void   QStatusBar::showMessage(...)
>>     void QProgressBar:: ...
>
> Uhm, huh? QStatusBar::showMessage() doesn't process any events. All it does
> is schedule a paint event and a timer event. And QProgressBar has no
> showMessage() function.

Yes. I was wrong. I'm getting old. Excuse me.

My problem with QStatusBar::showMessage was that the message would
not appear unless you returned to the event loop or explicitly called
::processEvents().  In my case, calling ::processEvents allowed other
queued activities to proceed when I was not ready.

And I meant QProgressDialog, not QProgressBar.
Use of QProgressDialog has embedded calls to ::processEvents with
the same problem.

> AFAIK the functions that create a local event loop are clearly documented
> as such, in particular those are usually called ::exec() and belong to
> classes that block user input from the rest of the application. And
> processEvents is not called in any widget or the like, only in QApp and
> QEventLoop related classes.

See the QProgressDialog::setValue(...)





More information about the Qt-interest-old mailing list