Description Dani Megert 2001-10-10 22:57:48 EDT

When resource is renamed then the following marker delta can come:
	a) marker added, marker removed
	b) marker remove, marker added

	Marker attributes are ok.
	The problem is that I can't know the target for the new marker.


NOTES:
DM (4/19/01 3:04:16 PM)
	Added IGroupByKeyComputer which must be passed to the search result
	view when a search is about to start.

DM (4/19/01 3:47:53 PM)
	Found bug in OverlayIcon... fixed

DM (4/19/01 3:49:13 PM)
	There is an open issue: Found out that when a CU is renamed (becaue the 
main
	type was renamed) the handle identifier is not updated. This is due to 
the fact that
	the resource in JavaSearchMarkerUpdater is not the new resource but the 
old one.
	This leads to a wrong handle identifier:

	A Java element which is created with this identifier throws 
JavaCoreExceptions on
	every attribute/info access.

DM (8/6/01 3:19:09 PM)
	Added a temporary fix to this PR which will correct the handle 
identifier when a 
	the corresponding resource of a Java element created via handle id is 
null in the
	JavaSearchResultLabelProvider: if the Java file name in the
	identifier is does not match the resource name then I fix it. I make
	assumptions on the handle identifier format.

	Fixing this PR in the JavaSearchMarkerUpdater will not interfere with 
this fix but the change should be removed first in order to test the correct 
fix.

DM (8/31/01 10:42:43 AM)
	Changed the code. The Marker updater will get a second change
	to fix the handle ID during a smart rename. However, currently all 
markers
	are deleted when a smart rename takes place.

	==> CURRENTLY MARKERS GET DELETED ON SMART RENAME.
	Kai (and I) waits for a fix from JCore:
		1FYE8XI: ITPJCORE:WINNT - JM - ISourceManipulation.delete send 
replace-BufferChangedEvent