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.
Copy of Jesse's arguments: Peter Zavadsky wrote: > I changed the firing events from RegistryImpl (and also other components like WindowManagerImp etc.) to asynchronous and always scheduled into AWT thread. Originaly it was changed due to older implementation of TC.requestFocus, which caused neverending looping when doing activating (which caused the even firing etc.)... to break > that loop. The older impl was changed, How? Probably you can just set a flag that you are inside the body of one method and to ignore your own change events you plan on firing. This breaks the loop. Or you may be able to somehow mark the event object as your own, etc. Or detach the self-listener before making the mutation, and reattach after (in a finally block). > but I left the firing of events that way so we can claim there are > always fired in AWT thread and that their handlers don't affect the > state of winsys if there are more changes performed during that task > inside winsys. Event handlers must not mutate the state of the event source. Feel free to enforce this with assertions. Set a flag before firing events (clear in a finally block) and assert !firing before processing any mutation-type events. > Example of the difference: before: 1) call TC.setActivatedNodes(nodes) in some thread, 2) you get property change from TC.Registry synch in that thread. Well probably wrong just because such calls should be in EQ. > now: 1) call TC.setActivatedNodes(nodes) in some thread, 2) you get property change from TC.Registry always asynch in AWT thread (event the above is AWT thread too -> it is still asynch). Not so good, I think. (1) You should not be permitted to call TC.setActivatedNodes out of EQ. I would strongly recommend the method start with assert EventQueue.isDispatchThread(); There is no compatibility issue here as it was always documented that winsys methods are EQ-only. Just enforce it. (2) If you call TC.sAN in EQ, IMHO the event should be fired synchronously. > I've read some time ago you recomended somewhere event firing to be synchronous. Generally yes. > If I understand right... that is if an object which is changed also fires the events (typically from its setter) it should follow that rule.... Right. > But I guess this is not case of winsys (the changed object TC is not the event source TC.Registry) which I see kind of swing system, where you get the event firing also asynch manner. What asynch manner in Swing system? AFAIK AWT/Swing components normally fire changes synch. I'm sure there are exceptions somewhere, but the rule is synch firing (and access only in EQ, except for text document models). -J. -- Jesse Glick <mailto:jesse.glick@sun.com> x22801 NetBeans, Open APIs <http://www.netbeans.org/>
Fixed in [trunk] Checking in core/windows/src/org/netbeans/core/windows/ModeImpl.java; /cvs/core/windows/src/org/netbeans/core/windows/ModeImpl.java,v <-- ModeImpl.java new revision: 1.16; previous revision: 1.15 done Checking in core/windows/src/org/netbeans/core/windows/RegistryImpl.java; /cvs/core/windows/src/org/netbeans/core/windows/RegistryImpl.java,v <-- RegistryImpl.java new revision: 1.4; previous revision: 1.3 done Checking in core/windows/src/org/netbeans/core/windows/WindowManagerImpl.java; /cvs/core/windows/src/org/netbeans/core/windows/WindowManagerImpl.java,v <-- WindowManagerImpl.java new revision: 1.17; previous revision: 1.16 done Processing log script arguments... Mailing the commit message to cvs@core.netbeans.org (from pzavadsky@netbeans.org)