Java 类javax.swing.plaf.synth.SynthUI 实例源码
项目：incubator-netbeans
文件：ThemeValue.java
private static SynthContext getSynthContext () {
try {
JButton dummyButton = getDummyButton();
ButtonUI bui = dummyButton.getUI();
if (bui instanceof SynthUI) {
return ((SynthUI) bui).getContext(dummyButton);
} else {
throw new IllegalStateException ("I don't have a SynthButtonUI to play with"); //NOI18N
}
} catch (Exception e) {
functioning = Boolean.FALSE;
if (log) {
e.printStackTrace();
}
return null;
}
}
项目：OpenJSharp
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：jdk8u-jdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：openjdk-jdk10
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：openjdk9
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：Java8CN
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：jdk8u_jdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：lookaside_java-1.8.0-openjdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：infobip-open-jdk-8
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：jdk8u-dev-jdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：jdk7-jdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：openjdk-source-code-learn
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：OLD-OpenJDK8
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：openjdk-jdk7u-jdk
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
项目：openjdk-icedtea7
文件：BasicTextUI.java
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}