Auto-Toggle DrawableButton still not updating images immediately


Latest Juce tip as of this posting (5d1da5fb794769be59bd597884c32cbb6d256216), I'm having issues with DrawableButtons not refreshing images properly (despite a fix from a month ago in 2cded82ea69769f357757fb8b30ee48e24f17a60.)

This is affecting my plugin when the window is freshly opened, and when parameters are changed via the host (changing programs, etc.) I've had to put workarounds such as this in my code to get around it, but it would be nice to be able to remove this stuff at some point:

if (myButton->getToggleState() == true) {


Sigh.. I don't know what's going on with the button logic, but it just seems to be impossible to make it work so that everyone's happy!

If you can give me a code-snippet to reproduce it (perhaps some code that could remain in the new demo for future testing?) then I'll have another look.


Perhaps I'm doing something wrong, but if so, I can't track it down. My plugin has an internal mixer with mute buttons that have Drawable image states for "muted" and "unmuted", so here's an example of the mute button for channel 1:


DrawableButton* C1Mute;


// Channel 1 Mute
    C1Mute = new DrawableButton ("C1Mute", DrawableButton::ImageRaw);
    C1Mute->setImages (cachedImage_mute_button_png,
    C1Mute->setClickingTogglesState (true);
    C1Mute->setButtonText (("Mute"));
    C1Mute->setTooltip (("Channel 1 Mute"));
    C1Mute->addListener (this);
    addAndMakeVisible (C1Mute);

I've been using this same code with previous Juce versions with no issues, but lately the changes to the Button classes have broken this so that I have to manually refresh the button's state separately from the button's toggle state.

Without that workaround in place, setRepaintsOnMouseActivity(true) is the only way to get this button to refresh its state - you can explicitly call repaint() to its component (and even recursively iterate through all child components issuing repaint() in a for loop!) without refreshing it - but for some reason a mouse hover will "wake" the button to its proper state, as will explicitly issuing a state refresh as shown in my previous post.

Come to think of it, I did just notice that I'm needlessly setting ButtonText for a purely Drawable raw image-based button with no visible text caption, so perhaps that's creating an unintended edge case. I don't even know why that's in there, this code has been essentially the same for a few years and that may be a scrap left over from prototyping... perhaps more tinkering is in order, but I'd be pretty surprised if that's the culprit - it would be odd in any case.


Well, let me know if you can give me a well-defined problem to look at. In my tests, all this stuff did seem to be ok.


I'll have to do some isolated tests. Sorry if this was a false alarm!


I am able to reproduce the issue with latest juce in some code that used to work as well.

This only happen with DrawableButton as it waits for buttonStateChanged to update the currentImage and do not handle it in realtime in paintButton according to the state.

In case of radio button, update is done silently on untoggled buttons with no notifcation called so this image is never updated.

repaint is called though.

It gets back to the right image as soon as you hover it as in that case buttonStateChanged is called.(mouseEnter, mouseExit)


Maybe the issue was that it use to call the SendStateChanged but not the click regarding notification and now it send nothing.



Now that you untoggle the button before toggling the new one, you can probably just put back line 122 in juce_Button.cpp:

turnOffOtherButtonsInGroup (notification);

so if you only check for buttonClicked, the last one is now the right one.




Painful as it is to make yet another tiny tweak to this stuff, I think you're right!