Emitted signals only processed once per event loop...

esmolikowski

Hi all,

Is there an easy way to configure a signal/slot to only be called once per event loop, even though its been emitted multiple times from different places in the code. Say I have a function that changes state, but calls other function that changes sub-states all those state changes emitting signals to refresh UI, auto-savings, or other. I'd like the slot to be called only once for the whole event loop.

I know I can deal with that manually with tracking the calls and state, and use a timer to reset state. However, I was wondering if there was a mechanism in Qt to say 'this signal should only be called once per event loop' so its handled internally instead of manually by the application developer.

Thanks.

esmolikowski

I took a look, and while there are different types of connections, there isn't a type that matches what I need, which is unfortunate. There is the following flag: SingleShotConnection, but it will be a SingleShot over the whole application (signal is automatically disconnected once emitted). I wish there was something like SingleShotConnectionPerEventLoop or something like this.

Christian Ehrlicher

How should this work? What is one event loop call? Someone might call process events somewhere - should count this too? Use a timer.

SimonSchroeder

Qt has nothing like this built in. Usually, there is a solution with two timers: The first is always reset when the slot should be called. During this short interval, more slot calls can be collected. However, this might delay indefinitely. Hence, there should be a second timer which is not reset while it is running and after a longer period (longer than the first timer) still calls the slot.

In the specific case of refreshing the UI: Just call update(). This one has what you want built in. It will not always just fire away. If you want to force an immediate redraw there is repaint().

esmolikowski

Thank you @SimonSchroeder. But I am not sure update() does what I need, not in terms of calling it just once, but in terms of updating the UI properly when values change. The way I do things right now is:

File loaded -> send signals -> change all values in UI (ie: update())
A selection has changed in some comboBox -> send signals -> change necessary values in UI (ie: update())
But what I am running into is the following:
File loaded -> send signals etc... When values change, the comboBox selection also changed -> send signal -> change necessary values in UI. Now the File loaded will change the same UI that the comboBox selection has triggered. Results in the UI update being called twice.

I hope that makes sense. I am not sure update() on a widget does that. I think update() is just to trigger a repaint of some widget because its content has changed.

jeremy_k

Use a single-shot 0 timer. Operations can request a service by starting the timer. The request can be repeated as many times as desired, but the timer will only fire once when the event loop next has a chance to service the timer event.

QCoreApplication app(argc, argv);
QTimer zeroTimer;
zeroTimer.setInterval(0);
zeroTimer.setSingleShot(true);
zeroTimer.callOnTimeout( []{ qDebug() << "timeout"; } );
zeroTimer.start();
zeroTimer.start();
app.exec();

mpergand

@esmolikowski

Have a look at QObject::blockSignals(bool block) and QSignalBlocker

https://forum.qt.io/topic/129364/blocking-signals-to-child-widgets/7