Description Sascha Radike 2006-03-07 10:51:03 EST

An ICElementDelta might report ICElementDelta.F_MOVED_FROM being set [calling .getFlags()], but .getMovedFromElement returns null.

This seems to happen if the user renames an ICContainer from a longer name to a shorter one. But not vice versa.

Exsample:
a) "Includes" -> Rename to -> "IncludesXXL"
*** This fires a celement delta event.
One delta child is for "Includes" (REMOVED) with F_MOVED_TO being set and .getMovedToElement() returning the moved-to Element.
The other delta child is for "IncludesXLL" (ADDED) with F_MOVED_FROM being set and .getMovedFromElement() returning the moved-from element.

NOW:

b): "IncludesXXL" -> Rename back to "Includes"
*** This fires a celement delta event, too.
The difference is: The delta for "Includes" (ADDED) with F_MOVED_FROM being set returns NULL if you call .getMovedFromElement().

I had a look at the (org.eclipse.cdt.internal.core.model) DeltaProcessor:

Example a) causes elementRemoved() being called before elementAdded()
Example b) causes elementAdded() being called before elementRemoved()

in elementAdded() in Example b) movedFromElement is not set. So it tries to create an Element for the movedFromPath. But this does not return an element (it's NULL) because the original ICConatiner has been deleted and the CModel does not create an ICContainer for a non-existent resource.

if  (movedFromElement == null) {
		movedFromElement = createElement(delta.getMovedFromPath());

So people relying on .getMovedFromElement() are in trouble.