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 7616 - PropertyChangeEvent "exceptions" is fired twice
Summary: PropertyChangeEvent "exceptions" is fired twice
Status: CLOSED INVALID
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P4 normal (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-09-12 10:39 UTC by Jan Becicka
Modified: 2007-09-26 09:14 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 Jan Becicka 2000-09-12 10:39:23 UTC 
[1098]
For example:

MethodElement me = clazz.getMethod(...

me.setExceptions(...

Two ProperyChangeEvents with "exceptions" as propertyName are fired.
Comment 1 Svata Dedic 2000-09-12 10:45:59 UTC 
I guess that (some of) identifier(s) you are passing to setExceptions() has not
its FQN filled in advance (e.g. its getSourceName() and getFullName() yields the
same value). If so, then e-mail me a confirmation because this is the intended
behaviour.
Comment 2 Jan Becicka 2000-09-12 10:59:59 UTC 
Your guess is right. I didn't fill FQN. If FQN is filled, only one
PropertyChangeEvent is fired.
Comment 3 Svata Dedic 2000-09-12 11:04:59 UTC 
OK, I'm setting INVALID for _now_.
Explanation:
If a partially qualified identifier is used in source text operations, the IDE
has no idea what exactly that identifier means. The IDE gathers that semantic
value from background reparse that is scheduled at the time the change is
written into the source.
So, the first property change event carries the identifiers as they are passed
to the setExceptions(). The second one is fired after the parser processes the
text, because the identifiers in the source model are DIFFERENT from the ones
produced by the parser, since those are fully qualified.

While this is (probably) the only one way how to satisfy general Java Bean's
property change listener concept, it _will_ change in the future. I'm fiddling
with some API/implementation of name resolution right now.
Comment 4 Quality Engineering 2003-07-01 13:12:34 UTC 
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 5 Quality Engineering 2003-07-01 13:17:47 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.