Signal/Slot loop?
-
Let's say you have a QCombo who's value you want mirrored in a QObject variable. The QObject has a slot called setValue and a signal called valueChanged. If you linked the setValue slot to the currentTextChanged signal from the QCombo, so that the value of the QObject would be updated to match the QCombo, but then also linked the setCurrentText slot on the QCombo to the valueChanged signal, so that the QCombo always matched the value of the QObject, would that create a loop where they would just continuously keep calling the signals/slots forever? Or does the Qt framework have some sort of protection to prevent this?
-
Let's say you have a QCombo who's value you want mirrored in a QObject variable. The QObject has a slot called setValue and a signal called valueChanged. If you linked the setValue slot to the currentTextChanged signal from the QCombo, so that the value of the QObject would be updated to match the QCombo, but then also linked the setCurrentText slot on the QCombo to the valueChanged signal, so that the QCombo always matched the value of the QObject, would that create a loop where they would just continuously keep calling the signals/slots forever? Or does the Qt framework have some sort of protection to prevent this?
@Dan203 said in Signal/Slot loop?:
Or does the Qt framework have some sort of protection to prevent this?
Nope. That's your problem in your own code. This particular case is usually resolved by ensuring you only raise a
valueChangedwhen the value is actually changing, not just being set, which stops the ping-pong signalling.You can assume Qt's own
valueChangedanddataChangedsignals are only raised when value/data is changed.For your particular widget-object case, note there is a QDataWidgetMapper Class. This manages the mapping between any widgets and their value in a map. You could use it for your example, or look at its code if you want to know how they do it.
-
@Dan203 said in Signal/Slot loop?:
Or does the Qt framework have some sort of protection to prevent this?
Nope. That's your problem in your own code. This particular case is usually resolved by ensuring you only raise a
valueChangedwhen the value is actually changing, not just being set, which stops the ping-pong signalling.You can assume Qt's own
valueChangedanddataChangedsignals are only raised when value/data is changed.For your particular widget-object case, note there is a QDataWidgetMapper Class. This manages the mapping between any widgets and their value in a map. You could use it for your example, or look at its code if you want to know how they do it.
@JonB said in Signal/Slot loop?:
@Dan203 said in Signal/Slot loop?:
Or does the Qt framework have some sort of protection to prevent this?
Nope. That's your problem in your own code. This particular case is usually resolved by ensuring you only raise a
valueChangedwhen the value is actually changing, not just being set, which stops the ping-pong signalling.You can assume Qt's own
valueChangedanddataChangedsignals are only raised when value/data is changed.That's what I figured, but wanted to make sure. Thanks
