[BUG] Can't change state of disabled ToggleButton

General JUCE discussion
1

Hey,

I noticed, that you can’t change the toggle state of a ToggleButton when disabled. Of course the user can’t and shouldn’t be able to by clicking, but calling button.setToggleState(...) was working in the past and I would expect it to.

Currently the workaround

const bool currentState{ button.isEnabled() };
const bool currentParentState{ getParentComponent()->isEnabled() };
button.setEnabled(true);
getParentComponent()->setEnabled(true);

button.setToggleState(...);

button.setEnabled(currentState);
getParentComponent()->setEnabled(currentParentState);

works for me, but that seems a little over the top to me.

2

I did some digging and traced the behaviour to this commit:

Guess it comes down to the question of desired behaviour. Personnaly I’d still like to be able to change a disabled component’s state.

3

I was the one who reported that original issue, and I agree with you. Thanks for finding that!

I hadn’t noticed this side-effect yet, but now, if you load a preset that has a togglebox disabled, it can show the wrong state - i.e. previous preset has the box enabled and checked; new preset has the box disabled and unchecked, but changing to it now leaves the box checked and disabled.

And actually, for me this is a big issue, because I can switch my interface between one of several “modules” having the same parameters, and depending on the disabled states, the ToggleButtons frequently end up displaying the wrong state.

4

This behaviour seems wrong to me. I think you should be able to set any control to any state whether it’s disabled or not - it’s up to the coder whether they want to process the state change when the control is disabled.

1 Like
6

@leehu - can’t agree. If the component is disabled, you are saying to the user “you cannot modify this at this time”. So allowing him to edit it, when editing it in the current state may cause undefined behaviour, and then you have to ignore it and return the control to the previous state, doesn’t make sense. Disabled means “you can’t edit it.”

That is different from allowing your code to change the state while it is disabled.

2 Likes
7

i was agreeing with you. i was talking about the developer being able to set the state of a control, not the user.

2 Likes
8

Yes I agree - disabled state should disable all user interactions (mouse, keyboard, etc.) but should otherwise behave the same on the backend including sending notifications when the state is changed programatically.

9

Oh - sorry! I misunderstood. I think we’re all on the same page.

10

This is obviously a very problematic commit that needs to be reverted. This is solving an edge case by breaking one of the big normal use cases.

11

Thank you for reporting. We’re looking at this issue.

12

I like how this kind of accessibility-related scenario invites us to rethink UI patterns we’re used to. Here, there’s an issue because we want to programmatically change the state of a component that explicitly says: “I have a state (toggled) and I can perform an action to change my own state; however, I’m also in a disabled state, so that action can’t be realistically performed in any meaningful way.”

If this behaviour is really desired, then it should be implemented using two separate components: one for the toggling action (e.g. a momentary switch button), which can be disabled if needed, and one for the state representation (e.g. a light indicator). In that case, it becomes clear that state and action are distinct. Accessibility is also naturally addressed this way.

That being said, I just discovered that an old app of mine is impacted by this commit, and I pulled my hair out as well :sweat_smile: But I still think this is a good invitation to rethink this UI pattern. Maybe the commit could be reverted, but with a warning about this bad practice?

13

A fix for this issue has been released on develop.

4 Likes
14

Thanks a lot for the quick fix!