Slider onValueChange callback behaves unexpectedly

#1

If you inherit from juce::Slider to implement your own custom slider, there are two ways to add custom “on value changed” behaviour to your class. Either:

void valueChanged() override {
   doCustomBehaviour();
}

Or:

onValueChange = [this] { doCustomBehaviour(); };

I noticed that both are being called if the user actually drags the fader, but only the first is called if I programmatically call mySlider.setValue (x);. I find this odd and confusing. Is there a deeper rationale here that I’m not getting? Thanks!

2 Likes

#2

That’s strange… I can’t seem to reproduce this (v5.4.3), both my callbacks are called when dragging or directly using setValue(). What kind of stuff happens in doCustomBehaviour()?

I see the lambda always being used in handleAsyncUpdate(), which is called either asynchronously or synchronously from the triggerChangeMessage() method above it:

0 Likes

#3

Yep, sorry, it was the fault of my unit testing framework, which made asynchronous calls not arrive (because there is no message loop).
So my question changes to: why does valueChanged receive callbacks synchronously or asynchronously, depending on what you specify, but the onValueChange lambda only gets them asynchronously?
Or, in other words, is there any way to have the onValueChange lambda being called synchronously? From my own eyeballing the JUCE code it seems that the answer is no.

0 Likes

#4

It seems the setValue() will pass the notification type on to triggerChangeMessage() which will then directly call handleAsyncUpdate() for synchronous notification types or triggerAsyncUpdate() for async notification types

Haven’t gotten to test it out myself but does the issue still happen when passing sendNotificationSync to setValue()?

0 Likes

#5

sendNotificationSync should unify things.

0 Likes