JDK-5080144 : REGRESSION: XP L&F: JTextField.setEditable() does not change background color
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-07-29
  • Updated: 2004-10-25
  • Resolved: 2004-09-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u1 betaFixed 6Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Tested in JDK 1.5 b60:  Setting the editable property of a JTextField (check also other text components), does not change the background color to gray (or the default platform's control color) in XP look and feel or GTK look and feel.  It does change it on JDK 1.4, and is inconsistent with other windows applications if the background of non-editable text areas remains white.

While this sounds trivial, it actually is quite an annoying accessibility bug - our users cannot tell which fields they need to fill in and which fields they don't - hence the high priority.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.5.0_01 mustang FIXED IN: 1.5.0_01 mustang INTEGRATED IN: 1.5.0_01 mustang
28-09-2004

EVALUATION Name: sh120115 Date: 07/29/2004 This is actually quite a frustrating issue and it has bounced around a lot. Here's the story: There's a difference between non-editable and disabled textfields. On Windows Classic and GTK L&F, non-editable textfields should look EXACTLY like editable textfields with the exception of not having a cursor. It is "disabled" textfields that have a different background. Unfortunately, the Windows Classic L&F still shows non-editable textfields with a darker background - this is WRONG and should be fixed at some point. However, the report here is about GTK L&F and Windows XP L&F. We've determined that what we're doing for GTK L&F is correct. I suspect it is for XP L&F too. Perhaps ###@###.### can confirm this and then close out the bug. Downgrading priority as this is not a Tiger showstopper. ###@###.### 2004-07-29 ====================================================================== will get to this bug for the next release ###@###.### 2004-07-29 ====================================================================== There is an interesting open source project https://winlaf.dev.java.net/ they find and fix winlaf incompatibilities https://winlaf.dev.java.net/release_0.4.html#Issue15 It seems that background color for noneditable components for XP L&f shoud be grey. ###@###.### 2004-07-29 ================ This was not desired behavior. This bug is a bug indeed. JTextFiled updates colors only if they are UIResource. Under windows look and feel UIManager.getColor() in some cases returns non UIResource color After that plaf does not change colors ever again. For exmaple switching from java look and feel to Windows look and feel and back to java look and feel makes JTextFiled ignore changing background colors on edit(enable/disable) XPStyle.getColor returns Color instead of ColorUIResource com/sun/java/swing/plaf/windows/XPStyle.java synchronized Color getColor(String key, Color fallback) { Color color = (Color)map.get("Color "+key); if (color == null) { String str = getString(key); if (str != null) { StringTokenizer tok = new StringTokenizer(str, " \t,"); int r = parseInt(tok.nextToken(), 0); int g = parseInt(tok.nextToken(), 0); int b = parseInt(tok.nextToken(), 0); if (r >= 0 && g >=0 && b >= 0) { color = new Color(r, g, b); map.put("Color "+key, color); } } } return (color != null) ? color : fallback; } The fix is : *** /ws/tiger/src/share/classes/com/sun/java/swing/plaf/windows/XPStyle.java Fri Jan 16 17:19:20 2004 --- XPStyle.java Fri Jul 30 18:31:44 2004 *************** *** 260,266 **** int g = parseInt(tok.nextToken(), 0); int b = parseInt(tok.nextToken(), 0); if (r >= 0 && g >=0 && b >= 0) { ! color = new Color(r, g, b); map.put("Color "+key, color); } } --- 260,266 ---- int g = parseInt(tok.nextToken(), 0); int b = parseInt(tok.nextToken(), 0); if (r >= 0 && g >=0 && b >= 0) { ! color = new ColorUIResource(r, g, b); map.put("Color "+key, color); } } This bug affect not only text components. reassigning to ###@###.### ###@###.### 2004-07-30 Name: sh120115 Date: 08/03/2004 While there may be a bug with XPStyle.java, I still maintain that the XP background should NOT be gray. ###@###.### points the following URL: https://winlaf.dev.java.net/release_0.4.html#Issue15 That issue points out that in 1.4.2 the background was gray, but that has been FIXED in the WinLAF project. The background is now the same as editable. ###@###.###, would you please have a look at some native components on your XP machine and set the story straight. ###@###.### 2004-08-03 ====================================================================== Regression was caused by fix for bug 4919687 in 1.5.0 b32, which added check for UIResource when the L&F wants to change the background. The problem is that the XP color values are not tagged as UIResource. Fix needed in XPStyle.getColor() as mentioned above. Also see Workaround section. The native behavior on XP is controlled by the current style. This will work correctly when this bug is fixed or when the workaround is applied to user code. Here is an excerpt from the XP style Luna.NormalBlue.ini: [edit] FillColor = 255 255 255 [edit.edittext(Disabled)] FillColor = 235 235 228 TextColor = 161 161 146 [edit.edittext(ReadOnly)] FillColor = 235 235 228 TextColor = 0 0 0 ###@###.### 2004-08-06
06-08-2004

WORK AROUND // Workaround for bug 5080144 in J2SE 1.5.0 // Insert this code after call to UIManager.setLookAndFeel(...) { String lafName = UIManager.getLookAndFeel().getClass().getName(); if (lafName.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) { UIDefaults uiDefaults = UIManager.getLookAndFeelDefaults(); Color c = uiDefaults.getColor("TextField.background"); if (!(c instanceof javax.swing.plaf.ColorUIResource)) { // Bug not fixed for (final Object key : uiDefaults.keySet()) { Object o = uiDefaults.get(key); if (o instanceof Color && !(o instanceof javax.swing.plaf.UIResource) && o == UIManager.get(key)) { UIManager.put(key, new UIDefaults.ActiveValue() { public Object createValue(UIDefaults table) { Color c = UIManager.getLookAndFeelDefaults().getColor(key); if (c != null && !(c instanceof javax.swing.plaf.UIResource)) { return new javax.swing.plaf.ColorUIResource(c); } else { return c; } } }); } } } } } ###@###.### 2004-08-06
06-08-2004

SUGGESTED FIX The fix is : *** /ws/tiger/src/share/classes/com/sun/java/swing/plaf/windows/XPStyle.java Fri Jan 16 17:19:20 2004 --- XPStyle.java Fri Jul 30 18:31:44 2004 *************** *** 260,266 **** int g = parseInt(tok.nextToken(), 0); int b = parseInt(tok.nextToken(), 0); if (r >= 0 && g >=0 && b >= 0) { ! color = new Color(r, g, b); map.put("Color "+key, color); } } --- 260,266 ---- int g = parseInt(tok.nextToken(), 0); int b = parseInt(tok.nextToken(), 0); if (r >= 0 && g >=0 && b >= 0) { ! color = new ColorUIResource(r, g, b); map.put("Color "+key, color); } } ###@###.### 2004-07-30
30-07-2004