How to use ButtonAttachment without setClickingTogglesState(true)?

I need to have an ImageButton with a ButtonAttachment that changes a (boolean) parameter, but should NOT hold its state. I want it to return to 0 when the button is released, not stay at 1. If I don’t call setClickingTogglesState(true), though, then my parameterChanged() function is never called for button presses. Is there a way to get my parameterChanged() function to be called without setClickingTogglesState(true) being called?

It looks like adding this to buttonClicked kind of works (instead of removing the setClickingTogglesState(true)), by resetting the button state immediately:

  bool isPressed = resetButton->getToggleState();
  if (isPressed)
    resetButton->setToggleState(false, sendNotification);

It looks like it sends the parameter changes to 1 and back to 0 both when the button is released, though. I’d prefer that it send the 1 when pressed and 0 when released, if possible.

Looks like I asked this same question a couple of years ago, and the only solution we found then was to use a custom-derived button class and trap the mouseDown()/mouseUp() events. Surprising that there is no such “PushButton” (as VSTGUI termed this button type) in the library. I’d think it would be really handy for things like keyboards in an audio plugin.

However I fail to see a keyboard to be modeled by AudioParameterBool?
Shouldn’t that be connected rather to the midi events than to automation?
How are change gestures handled to play nicely with recorded automation?

It sounds to me like an awkward workaround around a strange UX design, just my opinion…

Not sure what you are saying you find strange…? The idea of a button that issues a 1 when pressed and a 0 when released? The suggestion of using that design as an on-screen keyboard of some kind (which is not what I am using it for)? Or the need to sub-class the button ourselves for something that has been standard in VSTGUI for years? In any case, I need that behavior. Not for automation, just in general.

If it is not for automation, I suggest not to use AudioParameterBool. The AudioParameterXYZ classes are specifically designed to communicate automated values with the host. For anything else there are easier solutions.

If you put your value into a child node of APVTS’ state ValueTree, then you can connect any button using the Value object and referTo().

ValueTree MyProcessor::getMyProps()
{
    return treeState.state.getOrCreateChild ("MyProps", nullptr);
}

button.getToggleStateValue().referTo (processor.getMyProps().getPropertyAsValue ("button"));

Problem solved :slight_smile:

Well, we’re still on JUCE 5.3.2, so I don’t think that’s an option for us yet. We’re just using a ButtonAttachment to our parameter (which is in the APVTS, but is not an AudioParameterBool), and want our button to issue a down change and an up change. I just don’t get why that is a problem, and why it was not in the original set of button options.