Community
Participate
Working Groups
Build 20011211 - open org.eclipse.jface.actions.IAction - add method: public void setMenuCreator(IMenuCreator creator) { } - build - error mark shows up in task list and editor tab (method shouldn't have body), but not in hierarchy - make mod and save - hierarchy now shows tick - fix the problem and build - hierarchy still shows tick - make mod and save - hierarchy is now consistent
which errortick did not update correctly? In the type hierarchyies' method view? there is a open PR for this (bug 4359)
Mail from NE: Yes -> duplicate of bug 4359 *** This bug has been marked as a duplicate of 4359 ***
Bug 4359 cannot be the cause of this because associate and disassociate are not even being called on the hierarchy's viewer during the build. Try the steps above with autobuild turned off. Close all other views so you don't get spurious breakpoint hits. Add the breakpoints on associate and disassociate after saving but before the build. update is called once on the viewer on save (for the type) but this is unrelated. I'm not familiar enough with JDT's update mechanism to pursue this further.
Sorry for my poor description of the bug. I override 'associate' and 'disasociate' to build up a (own) hashtable to map IPaths to items containing elements with a underlying resource of this path. This informating is used to quickly update elements when marker deltas are notified. The bug is that some table viewer updates call 'associate' and 'disasociate' in a strange order. The hashtable so becomes incomplete, and no errortick updating is performed certain elements (-> errorticks are stuck or do not show up) These are the steps to illustrate the problems with 'associate' and 'disasociate': 1. in org.eclipse.jdt.internal.ui.typehierarchy.MethodViewer: set breakpoints in 'associate' and 'disasociate' 2. create class A public class A { void foo() { } } 3. Open type hierarchy on 'A' -> associate is reported for 'foo' 4. Add a new method to A void goo() { } 5. Save -> associate is reported for 'foo' -> disasociate is reported for 'foo' -> associate is reported for 'goo' This is how I loose track of 'foo'. I guess I should use mapElement & unmapElement. Please see bug 2741
Seems that I made a wrong conclusion about the call order of 'associate' and 'disasociate'. I should override 'mapElement' & 'unmapElement'. I would be happy if you could have a look at bug 2741 soon.
I've been looking at 2741, trying to find a way to avoid an extra call to mapElement if the element is unchanged, to avoid a performance hit. I'll try to address it soon. In the meantime, you could just try adding an extra call to mapElement in your override of associate. The performance hit is an extra map lookup, but at least only the methods viewer would be affected.
adapted to fixes for bug 2741
