Community
Participate
Working Groups
I20090505-2000 Note: This is an old problem (already in 3.4 and before) which we won't address for 3.5. When the user expands multiple nodes in the Call Hierarchy, the DeferredTreeContentManager only runs one search at a time. When the user now clicks the Cancel button, we cancel all expansions. Unfortunately, we only get an OperationCanceledException (in our DeferredMethodWrapper#fetchDeferredChildren()) for the expansion that is currently being calculated. In 3.4, we handled that by adding a "Search Canceled" node. In 3.5, we will properly collapse and refresh the parent such that search starts again when the user expands the node again. For all other pending searches, the DeferredTreeContentManager just calls runClearPlaceholderJob(PendingUpdateAdapter), which only removes the "Pending..." node, but does not collapse and refresh the parent. The fix probably requires changes in DeferredTreeContentManager (either to do the collapsing and refreshing for free in case the search has not been started yet, or to give clients hooks to do this properly).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This problem remains in current master. I should have checked for an existing bug before investigating it myself because I just came to the same result as Markus and also without a solution. You can use the small snippet below to easy reproduce the problem. Open call hierarchy for the method callHierarchy and the first expand the 'toString' child and second the 'print' child then cancel the search and find the state Markus described. (In reply to Markus Keller from comment #0) > For all other pending searches, the DeferredTreeContentManager just calls > runClearPlaceholderJob(PendingUpdateAdapter), which only removes the > "Pending..." node, but does not collapse and refresh the parent. > > The fix probably requires changes in DeferredTreeContentManager (either to > do the collapsing and refreshing for free in case the search has not been > started yet, or to give clients hooks to do this properly). From what I've seen this is almost possible. Removing the "Pending..." node produce an event which can be received via DeferredTreeContentManager.addUpdateCompleteListener. However I see no way to map such event to a specific finished update or to differ between success and cancellation. Snippet -------------------------- public class Bug275302_callHierarchyCancelSearch { public static void main(String[] args) { print(); } public static void print() { System.out.println(callHierarchy()); } public static String callHierarchy() { return "string"; } @Override public String toString() { return callHierarchy(); } }
