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 35916 - Generated setAction() call should be placed before other visual setXYZ() calls, for a given object
Summary: Generated setAction() call should be placed before other visual setXYZ() call...
Status: VERIFIED FIXED
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: All All
: P4 blocker with 1 vote (vote)
Assignee: Jan Stola
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-04 16:48 UTC by chrisnielsen
Modified: 2005-07-11 13:17 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description chrisnielsen 2003-09-04 16:48:34 UTC 
BACKGROUND: Today, it appears that the form 
editor generates setXYZ() calls in alphabetical 
order.  Normally, this is not an issue.  However, 
because of the way in which 
AbstractButton.setAction() works (existing visual 
properties are wiped out, and pulled from the 
action object when setAction() is called) the 
order of generated calls does matter for this 
case.

Since setAction() is near the top of the list 
alphabetically, things work most of the time.  
However, setAccelerator() comes before setAction
() alphabetically -- and the former is generated 
before setAction().  The end result is that the 
setAction() call effectively wipes out any 
accelerator set.

SUGGESTION: If possible, generate setAction() 
before any other setter methods.

SUGGESTED IMPLEMENTATION: To avoid any hard-
coding in the form editor, one possibility is to 
implement a simple property "priority override" 
scheme.  When generating code, the form editor 
would consult the priority override table (first 
by the class of the object who's code is 
currently being generated; second by by parent 
classes of the current object, searching in 
reverse order of class hierarchy) to see if any 
properties should be set first or last.  If so, 
do so.  Otherwise, generate code as is done 
currently.

Ideally, it would be nice if the overrides could 
also have a priority (so that, if more than one 
property should be set first, there is a 
definitive order).
Comment 1 Tomas Pavek 2003-09-17 17:40:59 UTC 
This is for JMenuItem only. But you are right that some mechanism for
specifying properties order is missing - however the properties should
be order-independent according to JavaBeans spec. See also issue
25834. A workaround is to provide setAccelerator code as setAction
property's post-init code in Component Inspector.
Comment 2 Jan Stola 2004-07-21 09:26:08 UTC 
Fixed - setAccelerator should be generated after setAction by now.
We added a hardcoded table that specifies dependent properties.
Normally the properties should be independent therefore
it doesn't seem to be appropriate to create a special UI that
would allow to change the dependencies (the introduced table
is more likely a hack than a feature).
Of course, it could happen that the table doesn't contain
some dependency (e.g. 3rd party bean is installed into
the palette etc.) In this case the workaround mentioned
by Tomas can be used.
Comment 3 Marek Grummich 2005-07-11 13:17:32 UTC 
Verified