[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