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.
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.
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).
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?
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).
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 anyway - In your Property object, return Boolean.TRUE from getValue("canEditAsText")... 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).
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.
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 { //snip 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.
> 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...
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) EnhancedPropertyEditor.
Okay, but what about my comment above? I.e. invoking the action even if the user does not change value, just presses Enter...
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.
Okay, I'll try.
Property panel rewrite branch merged.
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?
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 theProperty.getValue("initialEditValue"); 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.
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 StringInplaceEditor.java --- StringInplaceEditor.java 30 Jan 2004 21:51:09 -0000 1.11 +++ StringInplaceEditor.java 4 Feb 2004 16:28:44 -0000 @@ -61,7 +61,6 @@ boolean editable = PropUtils.checkEnabled(this, p, env); setEnabled(editable); setEditable(editable); - setText (p.getAsText()); reset(); added = false; } @@ -103,6 +102,7 @@ } if (txt == null) txt = ""; + setText(txt); setSelectionStart (0); setSelectionEnd(txt.length()); }
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.
Committed. /cvs/openide/src/org/openide/explorer/propertysheet/StringInplaceEditor.java new revision: 1.12; previous revision: 1.11 Continuing tomorrow with the event editor...
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 ;)