QTimer delayed timeout

[DavidY]

I have a custom QWidget with a QTimer set up in the resizeEvent function. The basic functionality of it is to execute some code only when the user has finished resizing the window (which in turn affects this QWidget). The code looks something like this:


CustomWidget::CustomWidget() : QWidget {

resizeTimer = new QTimer;
connect(resizeTimer, SIGNAL(timeout()), this, SLOT(resizeStopped()));

}

void CustomWidget::resizeEvent(QResizeEvent *event){

resizeTimer->start(5);
functionA()

}

void CustomWidget::resizeStopped(){
resizeTimer->stop();
functionB();
}

void CustomWidget::functionA(){
//code
}
void CustomWidget::functionB(){
//code
}

What I expected to happen was, while the window/widget was being resized, the timer would keep being reset until the resizing was paused long enough for the timer to timeout (in this case, 5 ms). However, for some reason when I have low intervals such as the 5 ms here, functionB() will only be called after my mouse has been released (after resizing the window). Higher values such as 100 ms work as expected, functionB() is called while the mouse is still pressed.

I'm not complaining, this is exactly what I want to happen, however I have no idea why it is, so I'm afraid it might raise some issues in the future which will confuse me. Anyone have any ideas?

Some additional information, is that functionA and functionB take some time to finish, around 50 - 150 ms. I was thinking this might be 'blocking' the timeout somehow if it times out before the function A/B has finished executing. I really have no idea though.

[Grimlock]

The timeout signal will only be delivered when control reaches the applications event loop.

[DavidY]

But wouldn't it delivered regardless of how long the timer interval is (as long as you wait long enough)? I don't understand why the short and long intervals have an effect.

[Grimlock]

My first thought is to change the connection type. Have You tried setting the connection type to Qt::QueuedConnection. Another reason why the slot is not evoked might be the rapidness with witch the signals are being sent. I think the application loop might be removing duplicated calls (as the windows event queue does).

[DavidY]

Changing it to Qt::QueuedConnection had an effect, the long intervals behave like the short intervals. Now another question is, why is the timeout signal queued? Qt::QueuedConnection says that "When emitted, the signal is queued until the event loop is able to deliver it to the slot." but I don't see why the event loop can't deliver to the slot until the mouse is released.