where does the Qt doc state this?
Nowhere, because it shouldn't matter to the user of QTimer
. The timer event is an implementation detail. It is delivered to the timer object itself, so you'd really have to go out of your way to intercept it. Here's how QTimer
works:
class QTimer : public QObject {
Q_TIMER
QBasicTimer m_timer;
protected:
void timerEvent(QTimerEvent * ev) override {
if (ev->timerId() == m_timer.timerId())
emit timeout();
}
/*...*/
};
If you think about it, there's no way of emitting any signals without running the code that emits the signals, and the only way to safely run such code that emits things asynchronously is to code for run-to-completion chunks that cede control to the event loop at every opportunity. The event loop is notified by the platform that a timer has timed out, and emits a signal right then. You'd be in deep trouble if Qt issued signals such as timer timeouts from intrusive asynchronous callbacks like Unix signals: just read about how few things you can do while in a signal handler - it'd be no different than an interrupt handler.
QTimer
andQTimerEvent
are two different ways of using timers in Qt. See the Qt doc for more information.QTimer
uses signal/slot communication whileQTimerEvent
(created byQObject::startTimer
and handled byQObject::timerEvent()
or and event filter) are, well, events. But both require an event loop in the current thread. – cbuchart