Bug 3420 - Problem with order of change listeners (1GKXGAT)
Summary: Problem with order of change listeners (1GKXGAT)
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: All Windows NT
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 6045 (view as bug list)
Depends on:
Blocks: 4247
  Show dependency tree
 
Reported: 2001-10-10 22:54 EDT by Martin Aeschlimann CLA
Modified: 2009-08-30 02:21 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2001-10-10 22:54:49 EDT
MA (01.10.2001 19:04:48)
	The type hierarchy view contains types and methods. When member filtering is turned on, the
	same view shows types and members.
	For hierarchy changes it listens as a  ITypeHierarchyChangedListener on a ITypeHierarchy,
	for tracking members removes/adds a IElementChangedListener is used.

	In the IElementChangedListener, I need the ITypeHierarchy to find out if my members are involved:
	I process the delta, I check all modified types if they are in the hierarchy, if yes, I have to update the members.
	I assume the hierarchy to be up to date when the IElementChangedListener is called.

	The problem is that a ITypeHierarchyChangedListener is triggered itselve from a IElementChangedListener.
	So when I access the typehierarchy, it could be that the type hierarchy has not yet send the 'hierarchy changed', but
	will immedeatly.
	I have to minimize the refreshes sent to the viewer, so there must be a way for me to synchronize the two change
	notification.

	- The type hierarchy delta can give me the element delta:
		Problem: Member changes does not imply a hierarchy change.

	- The type hierarchy is garuanteed to be processed before all  IElementChangedListener -clients, and the invocation of
	 a ITypeHierarchyChanged implies a IElementChange.
	I could then simply mark the hierarchy dirty when ITypeHierarchyChange comes, and do the update in the 
	IElementChange.

	- type hierarchy also reports member changes, even if the hierarchy itself is the same.


	
	

	



NOTES:
Comment 1 DJ Houghton CLA 2001-10-29 17:12:52 EST
PRODUCT VERSION:
	202

Comment 2 Martin Aeschlimann CLA 2001-11-21 06:11:53 EST
*** Bug 6045 has been marked as a duplicate of this bug. ***
Comment 3 Martin Aeschlimann CLA 2001-11-21 06:42:35 EST
The current state is that the type hierarchy (TypeHierarchyLifeCycle) contains 
a workaround where the element change listener is always added after the type 
hierarchy listener.
Having that, the type hierarchy change notification only sets a flag in the 
TypeHierarchyLifeCycle, but the change is processed in the following element 
change notification.

It's a workaround that makes assumtions that listeners order is not changed, 
and makes assumtions of how hierarchies are added as change listeners. These 
assumtions are undefined, so we should address the problem anyway.

I suggest that JavaCore has an internal queue of element listeners for type 
hierarchies. These listeners are notified first, before all client java element 
listeners.
Comment 4 Philipe Mulet CLA 2002-06-04 09:55:51 EDT
Defer
Comment 5 Denis Roy CLA 2009-08-30 02:21:31 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.