This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 44447 - Wizards regression - read only elements coloring
Summary: Wizards regression - read only elements coloring
Status: CLOSED INVALID
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: PC All
: P2 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords: JDK_SPECIFIC
Depends on:
Blocks:
 
Reported: 2004-06-07 15:44 UTC by zikmund
Modified: 2006-03-24 09:49 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zikmund 2004-06-07 15:44:06 UTC
Read only dialog elements should have different
coloring than active elements. Typical coloring is
having same background color as the dialog page.

This should be fixed for:
common panel of all file/class/package wizards
  - Project
  - Created folder/file
  [these are regression against 3.6]
new project wizard:
  - Description box

BTW: It's confusing for users to check everytime
which fields has to be filled and which are only
informative.
Comment 1 jrojcek 2004-07-27 18:34:41 UTC
What L&F is this bug filed against?
Comment 2 zikmund 2004-07-28 09:50:55 UTC
XP L&F

BTW: Reproducible on Win XP + JDK1.5.0-beta3-b59 (and sooner versions
of JDK 1.5). I think it could be JDK bug.
Comment 3 jrojcek 2004-07-28 13:46:08 UTC
So, it seems this is not an HIE issue.
Comment 4 _ ttran 2004-07-28 15:51:57 UTC
screenshot?  does it work on jdk 1.4.2?
Comment 5 Petr Hrebejk 2004-07-28 16:49:48 UTC
1. The description in Wizards is WONTFIX.

2. The other fields IS JDK bug. It works well with 1.4 and works wrong
on 1.5. (Win XP L&F and GTK L&F )

Tim you are good at filing P1 against JDK. Please do so and close this
bug. It seems like a real problkem to me. Uneditable input fields look
like editable on 1.5. They should rather fix it before the release.

Thanks 
   
Comment 6 _ tboudreau 2004-07-28 17:43:30 UTC
Okay.  Note that a simple workaround would be 

textField.setForeground (UIManager.getColor("textInactiveText")) - but
this may be a JDK bug anyway, because what I get in the property sheet
for that is the blue selection color, which is definitely wrong.
Comment 7 _ tboudreau 2004-07-29 04:49:15 UTC
True on GTK L&F as well, at least with b54
Comment 8 _ tboudreau 2004-07-29 05:07:25 UTC
textEnabledText is the correct value on windows look and feel.

I think you're calling setEditable(false) (which doesn't change the color, on 1.4 or 1.5 - I 
just tested it) where you need to call setEnabled(false) to change the text color as well (this 
definitely works on 1.4 and 1.5).  Back to you.
Comment 9 Petr Hrebejk 2004-07-29 14:45:17 UTC
Hmm strange. I just tested it and.

JDK 1.4.2 Enabled = true && Editable false => grayed out
JDK 1.5.0 Enabled = true && Editable false => NOT grayed out

Both      Enabled = true && Editable false => grayed out but in
standalone app only. In NB it still has a wrong color.

Very strange. A mx of JDK bug and some NB hack?

Tested on Win XP
Comment 10 _ tboudreau 2004-07-29 15:59:28 UTC
Filed as JDK bug 5080144 with high priority.
Comment 11 zikmund 2004-08-05 11:22:59 UTC
BTW it seems to be fixed in NB in build 200408041800. Did you
implement some workaround?

Marking as verified (although I don't understand why it's invalid and
not fixed, but it works now, so I'm just inquisitive - result is most
important thing)
Comment 12 _ tboudreau 2004-08-05 12:58:25 UTC
Yes, there is a workaround for the JDK bug - a few of the colors in the UIDefaults table are 
not instances of ColorUIResource, but should be.  JTextField, et. al., check the value, and if 
the colors are instances of ColorUIResource, then they will change them on the fly - but if 
they are instances of Color, they will assume that they were intentionally set and should 
not automatically be changed.  Unclear whether the JDK bug will be fixed for 1.5 or not - 
it's getting late for them.

I put in a workaround to just grab the three problem values from UIDefaults, and if they 
are instances of Color, wrap them in instances of ColorUIResource and put them back.