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.
dev build 200312111900 Tools | Import Management Tool | ... Some of the entries shown by this wizard are non-editable (and never will be) yet they still display "..." beside their value.
Well, there are plenty of cases in NetBeans where a disabled property is too long to fit in the property sheet or tree table, but if the user actually wants to read the whole thing, the custom editor is the best way to do it. I agree, it's not useful for a lot of things - I've proposed suppressing the custom editor by default for String properties, and making the exceptional case when one is actually used. However, it's a backward-incompatible change. WRT the specific issue of the import management tool, the Property objects that are non-editable should do supply the following: Boolean.FALSE.equals(theProperty.getValue("suppressCustomEditor")) - if they do that, no custom editor button will be displayed. As a side effect, it will improve performance on WindowsXP look and feel - I did some profiling yesterday, and custom editor buttons in TreeTableView on XP look and feel spend 13% of their painting time just scaling the bitmap for the XP button border. Reassigning to the java module, though I may go so far as to also put together a patch.
There is also the question of whether the import management tool will still exist in future versions - one of the features on the planned list is more transparent management of imports. Also, the IMT is currently quite buggy with regard to inner classes, and difficult to use (a long time ago I submitted a patch to fix the fact that it relies on settings you can't change without closing the dialog and fishing around in Options - I added a "low noise/high noise" combo box that aggregated the settings into something that you could set in the wizard and would usually do the right thing. I've seen it make a mess more often than work properly. Up to the Java module folks.
Created attachment 12565 [details] Trivial patch for the java module which fixes the problem
Given how trivial the fix for this was, I've committed it. Checking in AbstractProp.java; /cvs/java/src/org/netbeans/modules/java/imptool/AbstractProp.java,v <-- AbstractProp.java new revision: 1.3; previous revision: 1.2 done Processing log script arguments...