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 8966 - showing property value when textfield disabled
Summary: showing property value when textfield disabled
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P4 enhancement (vote)
Assignee: David Strupl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-12-20 23:26 UTC by Jan Benway
Modified: 2008-12-22 20:45 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Benway 2000-12-20 23:26:26 UTC
In many cases it is useful to have a property where you do not want to allow
the user to directly edit the property's value in the property textfield or in
a dropdown menu, but instead force the user to use the "..." button to edit
the value.

This is useful for properties where you need to be sure the user's input is
valid. The ... can bring up a property editor and you needn't validate input
that the user types into the text field.

The problem is that if you disable the textfield and the value is something
other than String, the type that the property expects is shown instead of
something with more meaning to the user.

An example is in the component inspector. Look at the font property for an
object. The textfield is disabled but there is a ... button to edit it.
The font is shown as the value, but this value is "drawn" into the properties
sheet.

What we'd like is:
*enabled property
*expected value is not String
*disabled textfield, no dropdown menu (like font property)
*allow module developer to provide a string to display as the value of the
property.
Comment 1 Jesse Glick 2000-12-21 11:05:59 UTC
This would be an API change--move further away from JavaBeans specification.

Note that the Font editor implements paintValue to specially display its value,
so getAsText -> null. However it is not reasonable for most propeds to do this
as for GUI consistency it requires knowledge of how regular textual value
painting appears (font, colors, positioning, ...) and is cumbersome.
Comment 2 David Strupl 2001-01-18 14:59:59 UTC
Do I get it right that what you request is to expose the code that paints the
string and make your property editors in place paintable and call this
exposed code? Maybe we could put such a code into the util package or somewhere.
Jesse?
Comment 3 Jesse Glick 2001-01-18 16:36:59 UTC
It sounds like an ugly solution to me... the basic request should have been
solved by JavaBeans API but was not, i.e. getAsText but not setAsText in a
proped. Maybe we could have a proped hint "PROP_SET_AS_TEXT_DOES_NOTHING" ...?
Comment 4 Rochelle Raccah 2001-01-18 17:06:59 UTC
Jesse's comments are correct.  We don't want the painting code exposed, we just
want a way to specify to the property editor that this is the desired behavior.
I discussed this with Jesse back in June and the shortcoming of the JavaBeans
spec.  It was decided that the IDE's property editing could provide this as an
enhancement.
Comment 5 David Strupl 2001-01-18 17:19:59 UTC
Ok, I will add the special proped hint as Jesse suggests.
Comment 6 David Strupl 2001-01-19 09:24:59 UTC
You can now pass custom property with name "canEditAsText"
 in the beaninfo, for example like this:
properties[PROPERTY_justString].setValue("canEditAsText", Boolean.FALSE);
More details from where you can pass this here
http://www.netbeans.org/www-nbdev/msg03079.html
The value must be Boolean.
Hope this helps. Marking this bug as fixed. If there are any problems
with this, please reopen or file a new bug report. Thanks.
Comment 7 Quality Engineering 2003-07-01 15:56:29 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 8 Quality Engineering 2003-07-01 16:15:16 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.