How to disable a container and its children in Swing

Question

I cannot figure out a way to disable a container AND its children in Swing. Is Swing really missing this basic feature?

If I do setEnabled(false) on a container, its children are still enabled.

My GUI structure is pretty complex, and doing a traversion of all elements below the container is not an option. Neither is a GlassPane on top of the container (the container is not the entire window).

Answer 1

To add to mmyers's answer, disabling children is not an easy task (see this thread)

The problem is near-to unsolvable in the general case. That's why it is not part of core Swing.

Technically, the disable-and-store-old-state followed by a enable-and-restore-to-old-state might look attractive. It even might be a nice-to-have in special cases. But there are (at least, probably a bunch more) two issues with that.

Compound components

The recursion must stop on a "compound component" (or "single entity"). Then the component is responsible for keeping dependent's state. There's no general way to detect such a component - examples are JComboBox, JXDatePicker (which as related issue)

To make things even more complicated, dependents don't need to be under the hierarchy of the "compound component", f.i. JXTable takes care of the ColumnControl's (and header's) enabled state.

Trying to tackle both would require to have

a) a property on the compound: "don't touch my children" and
b) a property on the uncontained dependents: "don't touch me"

Binding to enabled

enable-and-update-to-old might break application state if the enabled status is bound to a (presentation or other) model property and that property changed in-the-meantime - now the old-state is invalid.

Trying to tackle that would require to have

c) a "real" stored-old-enabled-due-to-view-concerns property
d) bind the presentation model property to both the enabled and the stored-old-enabled

JXRadioGroup has a variant of that problem: On disabling - the group itself or the general controller - keeps track of the old-enabled of every button. Button's enabled is controlled by the Action - if there is an Action. So the enabled controller needs to restore to old-enabled or to action's enabled. During group's disabled (as-group) a problem looms if the Action's enabled was false on storing and changed to true. Another if actions are added.

Now imagine the complexity of state transitions when overloading a)-- d)

Answer 2

This is what I came up with.

Component[] comps = myPanel.getComponents();
for (Component comp:comps){
    comp.setEnabled(false);
}

Answer 3

As VonC's answer, there's no simple solution existed. So i recommend you to programe with a supporting infrastructure from the start.

A simple infrastructure is likely to be, for example, using delegated listeners that do a "event enabled" check from a super container's flag before actual event-respond:

class ControlledActionListener extends ActionListener {
    ...
    public void actionPerformed( ActionEvent e ) {
        if( !container.isEnabled() ) return;

        doYourBusinessHere();
    }
}

Or even better, you can use the APT to automatically inject the boilerplate code for you.

This works well all the time. It's the clean way to block both user interaction and programming calls with a single effort. Even though it costs you some codes to support the underlying functionality, you get simplicity, usablity and stability in return.

PS. i'd like to see better solution to this problem.