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 26367 - Empty drop-down list for Event Handler values
Summary: Empty drop-down list for Event Handler values
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: issues@guibuilder
Depends on: 31896
Blocks: 33994
  Show dependency tree
Reported: 2002-08-08 02:49 UTC by eadams
Modified: 2004-02-05 17:15 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description eadams 2002-08-08 02:49:17 UTC
When you click on the value of an Event Handler property you
get a drop-down arrow for a combo-box and an elipsis button.

When there are no event handlers, the drop-down list is empty
and clicking on the arrow displays an empty list.  This has no
value and the drop-down arrow takes up valuable space (see
issue 26350 and issue 25935).

I recommend that the drop-down arrow should not be displayed
when there are no handlers.  Additionally, it should not be necessary
when there is just one handler as that name can be seen in
the text area.

Since it is rare to have more than one handler, these changes would
make the drop-down arrow disappear in almost all the cases.
Comment 1 Tomas Pavek 2002-08-08 08:58:58 UTC
Unfortunately, there's no easy way to not display drop-down button of
a combo-box. The combo-box should be rather replaced with a textfield.
But it's rather non-trivial change to be done for NB 3.4 now (and not
so urgent IMO).
Comment 2 eadams 2002-08-08 13:42:22 UTC
Agreed, if there is no easy way to do this, then it
should not be considered for 3.4.

I'm curious about the current implementation.  It appears
that a textfield is used before the user clicks and that
it is then replaced by a combo-box and a "..." button.
Is the how it's implemented?
Comment 3 Tomas Pavek 2002-08-08 14:11:26 UTC
It's probably JLabel or JButton in read state (provided by property
panel form openide) and JComboBox in write state (provided by form
editor; followed by ... button provided by property panel).
Comment 4 _ tboudreau 2003-06-30 15:36:48 UTC
FYI, the Color editor does this (type in "control" for a color value
and it notices you typed a Swing UIManager color name and gives you
a drop-down).

What I *think* you need to do here (I don't know the details of what
the form editor is doing, but it should work):

 - Get rid of the EnhancedCustomProperty editor - it's deprecated
 - In your Property object, return Boolean.TRUE from  
   that hint to the editor to enable editing of the combo box's 
   contents (in the new property sheet, anyway)
 - Implement ExPropertyEditor for your editor.
   If no candidate methods exist, return null from getTags,
   else return the candidate methods.
 - If a candidate method is created, you can fire a property
   change (null, null, null) from your node to make sure
   the property sheet repaints - but this shouldn't even be
   necessary, since whatever created the property is going
   to have changed the selected node anyway (at least I
   can't think of any way you can avoid doing that, and the
   new property sheet doesn't cache *any* info about the 
   property editor, the result from PropertyEditor.getTags(),
   or even the Property object).

In short, there's no need to be supplying your own combo box
for this property anymore - the standard infrastructure can
do everything you need (and look better too).
Comment 5 Tomas Pavek 2003-07-01 09:53:39 UTC
I'm still not sure if the standard infrastructure can do everything
needed instead of custom combo box, otherwise it would be already used
that way. What I remember at least is ActionListener and Enter key
listener on the combo box for switching focus into editor to selected
event handler. This cannot be done on setValue of the property editor
I think. But maybe this could be workarounded somehow, we'll see.
Comment 6 _ tboudreau 2003-07-01 17:33:22 UTC
I'm guessing the problem is that the property editor can't
differentiate between the value being set to initialize the
property editor and the value being set by the user.

Question:  If I allowed you to provide a hint from your 
Property, so that you could supply an Action that could be
performed after the *user* sets the value successfully,
would that be enough?  It seems like a reasonable enough
requirement.  So you would do something like:

public MyProperty extends Node.Property {
  public void getValue (String key) {
    if ("postSetAction".equals (key) {
       return new Action () {
          public void actionPerformed (ActionEvent ae) {
             //update the editor

It seems like something other property editors may need,
and this would be a fairly clean way to do it, consistent
with other hinting options.

An alternative would be, in the new property sheet, to 
provide your own InplaceEditor (a replacement for the
deprecated EnhPropertyEditor custom inplace editor code
with a real contract for how and when the value should
be taken).  But since it would be identical to the existing
combo box inplace editor, it doesn't make a lot of sense
to me to force you to reinvent the wheel.
Comment 7 Tomas Pavek 2003-07-04 15:36:19 UTC
> I'm guessing the problem is that the property editor can't
> differentiate between the value being set to initialize the
> property editor and the value being set by the user.

That's it, but still not exactly. I think it could work the way you
suggest. But still the problem is in the definition of "user sets the
value successfully" - this implies the value is changed, but in the
case of event handler in form editor, it's enough just to press Enter
or re-selecting the value in combo without doing a change...
Comment 8 _ tboudreau 2003-11-16 12:06:07 UTC
I have a solution for you that will work once the property panel
rewrite is merged.  It's not pretty, but it's consistent with the
other hinting methods used by other property editors.

The problem:  setAsText/setValue on properties or property editors do
not differentiate between the value being set programmatically and the
value being set by a user.

The solution:
You may now return an implementation of Action from your property's
getValue(String) method (whether you override it or call setValue to
install it in your constructor is up to you - IMO overriding it is the
cleaner way).  The action will be run only when the *user* explicitly
sets the value.

You may then choose to use a combo or not - just return null or
non-null from getTags() as needed.  You'll also need to return
Boolean.TRUE from myProperty.getValue("canEditAsText") so the user can
edit the combo box.  But you'll be able to de-complicate your code
quite a bit, and no longer use the deprecated (and semi-supported)
Comment 9 Tomas Pavek 2003-11-18 17:08:10 UTC
Okay, but what about my comment above? I.e. invoking the action even
if the user does not change value, just presses Enter...
Comment 10 _ tboudreau 2003-11-19 15:50:37 UTC
I can do it either way - right now, it is only run if the code that sets the 
property to the value from the property editor returns true.  But that's not 
absolutely necessary - I put this stuff in for you guys. 
So I just commented out the check if the result was a real change.  If you 
want to build of the proppanel_rewrite2 branch (see issue 31896 for how to 
do this), you can try it. 
Comment 11 Tomas Pavek 2003-11-19 16:41:41 UTC
Okay, I'll try.
Comment 12 _ tboudreau 2003-12-09 09:36:53 UTC
Property panel rewrite branch merged.
Comment 13 Tomas Pavek 2004-01-30 15:47:02 UTC
Reopening, this is actually not fixed. Some work needs to be done on
form editor side.

Question for Tim: The post edit action works as needed, but I've found
another problem when trying to replace the EnhancedPropertyEditor for
event handlers editing: now, when the user enters the editing field
and no event handler was specified (getAsText() returns "<none>"), the
created in-place editor (custom combobox) is pre-set with an
automatically found handler name - so when the user clicks on the
event, "<none>" is changed to e.g. "jButton1ActionPerformed". But this
is not possible without providing own in-place editor. Any ideas?
Comment 14 _ tboudreau 2004-01-30 21:52:50 UTC
Well, there wasn't a way to do this...I just created one:

When setting the initial value, the string and combo editors will now check


If that is not null (it must be a String), that value will be used when initiating editing.
It's not heavily tested, but should work fine.  Let me know if there are any problems.
Comment 15 Tomas Pavek 2004-02-04 16:29:52 UTC
Cool, thanks! However - it does not work now ;)
StringInplaceEditor.reset() actually does not set the string to the
text field - a bug that should be fixed anyway. Method connect()
probably needs not set the text then if reset() is called from it.
I've just try it for myself and it works. The diff:

diff -u -r1.11
---	30 Jan 2004 21:51:09 -0000	1.11
+++	4 Feb 2004 16:28:44 -0000
@@ -61,7 +61,6 @@
         boolean editable = PropUtils.checkEnabled(this, p, env);
-        setText (p.getAsText());
         added = false;
@@ -103,6 +102,7 @@
         if (txt == null) txt = "";
+        setText(txt);
         setSelectionStart (0);
Comment 16 _ tboudreau 2004-02-04 17:54:49 UTC
Please go ahead and commit the change - not much reason to open a separate issue just 
for this.  You are right, the text should only be set in reset() - that's what it's designed for.  
Comment 17 Tomas Pavek 2004-02-04 18:35:21 UTC
new revision: 1.12; previous revision: 1.11

Continuing tomorrow with the event editor...
Comment 18 Tomas Pavek 2004-02-05 17:15:22 UTC
So I've finally made it work. Thanks Tim for cooperation. The strange
and complicated event property editor is out. (And another strange
property editor is in ;)