I have a Slider that’s bound to a Value using slider.getValueObject().referTo(parameterValue). After a bug report, I found that Slider::valueChanged() is not being called when the value changes from the parameterValue. The reason is this line.
Why is dontSendNotification being used here? The docs for Slider::valueChanged() do say:
Callback to indicate that the user has just moved the slider.
But then the method should be called e.g. movedByUser. The name valueChanged suggests that it is called whenever the Slider’s value has changed, no matter from where.
If valueChanged() sent notifications for that, then it would cause an endless loop, wouldn’t it? The setValue() call would trigger a valueChanged() call, which would call setValue() , which would…
How are you changing the value when you observe this as a problem? Perhaps you need to use a method that forces the callback, such as setValueNotifyingHost() (if it’s a parameter), or call valueChanged() directly? (I’m not familiar with binding to a Value, so I’m not sure of the specific protocol for manually changing the value such that it notifies the listener(s).)
There are two valueChanged here: Slider::Pimpl::valueChanged (Value&) to receive Value changes, and Slider::valueChanged() to notify the subclass. The loop could be resolved with a scoped flag, as it’s usually done. I see the problem with this -the self callback can be used to update the slider image (there could be, for example, an animation for value changes). As it is, the subclass would have to listen to the referred Value, which kills the point of using referTo.
valueChanged() would only be called if the actual number has changed. So it would only continue notifying until everyone has the same new value.
I guess valueChanged is referring to the current „value“ not the Value() class itself.
The Slider’s value is held in a Value, they aren’t separate. For example, Slider::getValue() just calls Value::getValue() internally. So if the Value object changes, it affects what Slider::getValue() returns. So a method with the name Slider::valueChanged() should be called in this case.
there could be, for example, an animation for value changes). As it is, the subclass would have to listen to the referred Value, which kills the point of using referTo.
Yeah, this is my use case For now I did it by listening to the Value directly…my point was just that the name Value::valueChanged() is misleading.
This is owed to how C++ works. Listener is just a mnemonic word, to the compiler all those Listeners have no relation with each other.
To make the function clear, they could all have the same name, but since you add the Listener interface from several broadcasters to one concrete subclass by multiple inheritance, the compiler needs a way to destinguish them. The nested namespace is lost with the inheritance, but the argument list is still there to figure out, which valueChanged to call.
Methods are never destinguished after the return type (but that is void in all Listener cases anyway).
For now I did it by listening to the