Why is it impossible effectively to override Swing's setEnabled?

Question

My goal is to prevent setEnabled in Swing from graying out my JLabels and other JComponents into unreadability. (The reason for this is that I have another solution to indicate enabled status - icons.)

Based on SO answers to one of my previous questions, I decided to override setEnabled. Yet as you will find below, my overriding of setEnabled still results in components becoming grayed out, despite the lack of any call to super(toggle). Can someone explain why it appears impossible effectively to override setEnabled's behaviour?

public class ToggleLabel extends JLabel {

private boolean toggle;

public ToggleLabel(String text, boolean toggle) {
    super(text);
    setEnabled(toggle);
}

public ToggleLabel(Icon image, boolean toggle) {
    super(image);
    setEnabled(toggle);
}
@Override
public void setEnabled(boolean toggle) {
    this.toggle = toggle;
    System.out.println("I am used");

}
@Override
public boolean isEnabled() {
    return toggle;
}

}

Instead of changing the enabled state, would it make sense to simply _not show_ the [relevant components](http://stackoverflow.com/q/9707470/230513)? — trashgod, Mar 18 '12 at 03:44

score 3 · Answer 1 · edited May 23 '17 at 12:20

There's nothing special with Swings setEnabled function, you can override it as any other function. Invoking someToggleLabel.setEnabled(false) in your code will obviously not disable the JLabel (by fundamental Java semantics). Something else must be wrong.

If you want to be able to disable the component (as it seems since you say you have another way of showing it) I suggest you don't "disable" the mechanism swing provides for disabling a component but instead try to change the look and feel some how.

Have you for instance considered using JLabel.setDisabledIcon?

Related questions which you might find useful:

+1 for your helpful response with suggestions and related links. — Arvanem, Mar 17 '12 at 23:38

score 3 · Answer 2 · answered Mar 17 '12 at 23:23

3

I don't know why you think so, for example, take this program:

package so;

import java.awt.Color;
import java.util.Arrays;

import javax.swing.Icon;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;


public class Example {

    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                JFrame f = new JFrame();
                JPanel p = new JPanel();
                ToggleLabel tl = new ToggleLabel("hello");
                p.add(tl);
                tl.setBackground(Color.GREEN);
                tl.setEnabled(false);
                f.add(p);
                f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                f.pack();
                f.setVisible(true);     
            }
        });
    }

    private static class ToggleLabel extends JLabel {

        private boolean toggle;

        public ToggleLabel(String s) {
            super(s);
        }

        @Override
        public void setEnabled(boolean toggle) {
            this.toggle = toggle;
            System.out.println("I am used");

        }
        @Override
        public boolean isEnabled() {
            return toggle;
        }
    }

}

As you can see, "I am used" is printed, and the program, when running, look like this:

enter image description here

answered Mar 17 '12 at 23:23

MByD

135,866
28
264
277

Thank you for taking the time to code. However the fundamental problem of graying out still subsists. :( – Arvanem Mar 17 '12 at 23:27
have you seen the screenshot? It doesn't look like it. – MByD Mar 17 '12 at 23:28
Thank you for uploading proof. Something else really must be wrong as Aioobe points out. – Arvanem Mar 17 '12 at 23:29
I agree with Aioobe, but what you are talking about is basic Java, and the call to this method is direct, so there should be no problem implementing it (though it might be bad idea) – MByD Mar 17 '12 at 23:31
I appreciate it and will reconsider. But it's very odd - the graying out persists with my code above. I wonder if it's connected with my not calling setEnabled (overridden) externally but inside the ToggleLabel class. +1 for your answer and comments. – Arvanem Mar 17 '12 at 23:37
@Arvanem, no, that shouldn't matter. If you post more code in your question (preferrably a [SSCCE](http://sscce.org)) we would be able to help you further. – aioobe Mar 18 '12 at 06:56
@BinyaminSharet : Actually when i run this program, as coded by you, the item in question is `colourless`. I am on Windows 7, so might be the `LnF` has got something to do with this thing, as to why what you getting is not what others are getting. – nIcE cOw Mar 18 '12 at 08:36

Java42 · Answer 3 · 2012-03-17T23:57:04.467

3

Your setEnabled() override is working at noted by the print statement.
To prevent a component from being disabled override isEnabled() and return true:

 public boolean isEnabled() { 
    return true;
 }

edited Mar 17 '12 at 23:57

answered Mar 17 '12 at 23:45

Java42

7,628
1
32
50

score 3 · Accepted Answer · answered Mar 18 '12 at 02:18

3

The enabled/disabled appearance is controlled by the component's UI delegate for a chosen Look & Feel. For example, a button's delegate typically derives from javax.swing.plaf.ButtonUI.

answered Mar 18 '12 at 02:18

trashgod

203,806
29
246
1,045

score 0 · Answer 5 · answered Mar 18 '12 at 00:15

If your problem is that the foreground or background colour is not what you want, add an override to setForeground or setBackground, put a breakpoint in that method and run it through the debugger. Then look at your stack when the breakpoint is hit to determine the problem. Sometimes it's calls to setEditable that I've found are causing me problems. HTH and good luck ;)

score 0 · Answer 6 · edited May 23 '17 at 12:04

I noticed, on different occasions, that the overriden setEnabled method I wrote on my own components (I usually extends from JPanel) was called at instanciation time. Of course my own constructor didn't call it explicitly.

So, this means that JPanel or one of its ancestors calls setEnabled (maybe indirectly) in its constructor.

It is dangerous to override a method that is called in an ancestor's constructor, maybe this is the cause of your problem. See What's wrong with overridable method calls in constructors? for more infos about this issue.

Why is it impossible effectively to override Swing's setEnabled?

6 Answers6