Community
Participate
Eclipse IDE
N20050602-0010 - Debug the class below with the breakpoint where indicated. - Expand t1 in the Variables view -> expands fine and shows fID and fName. - Expand t2 -> only child fID is shown package xy; public class Try { String fName; int fID; public Try(String name, int id) { fName= name; fID= id; } public static void main(String[] args) { Try t= new Try("Hello", 5); callee(t, t); } static void callee(Try t1, Try t2) { boolean same= t1.equals(t2); //breakpoint here } }
It's due to a problem in AbstractTreeViewer - which assumes an elemnet can only exist once in the tree: createAddedElements(...)/itemExists (items,element). The tree thinks the variable "fName" already exists (because it checks the cache of elements in the cached map), and just ends up refreshing the existing node in the tree, rather than adding a new one.
I thought a similar problem might occurr in the package explorer when showing overlapping working sets. However, the code path is different. The package explorer works in the main thread when a node is expanded, which assumes the children cannot be present yet. The variables view works in the background and performs "adds", which results in this problem.
Note that the PackageExplorer uses a tweaked TreeViewer to allow showing the same element twice. The example from comment 0 worked fine in M6 - something must have changed between M6 and M7 that influences duplicate element handling.
It appears the fix to bug 92835 has broken the variables view. The private method itemExists(Item[] items, Object element) cannot be overriden. I will have to see if we should not be using an element map.
Correct - the issue is with using a hashmap for lookup which assumes no duplication. You will have this issue with any TreeViewer until there is true support for duplicates
Changing to not use hashlookup, labels don't update properly. Only the labels for the first elements appear. Labels for the dups remain as "..." as the background label update finds/updates the first occurrence.
Truth is that TreeViewers don't support multiple matches - I think any change we make or any new code path you use could get you into this trouble (as you just saw). You could copy internalAdd down to try and work around this - I really don't want to make itemExists[] API as it is not meant to be and it would be hack to get around the use of the tree viewer in an unsupported way.
*** Bug 99614 has been marked as a duplicate of this bug. ***
Deferred for post 3.1. Too late for changes in 3.1, need to re-examine trees with duplicate elements post 3.1.
*** Bug 100881 has been marked as a duplicate of this bug. ***
*** Bug 100720 has been marked as a duplicate of this bug. ***
*** Bug 101565 has been marked as a duplicate of this bug. ***
Isn't this bad enough to delay 3.1? That is, I have hard time believing that users would knowingly accept a debugger with this bug. Btw do you know how annoying it is to hunt through all of the variables in the view trying to find the one element that has the right ID _and_ is showing all the fields? Sure with this example and the one I provided the problem is not too bad. However try it when you have bunch of lists and trees to deal with!
As a workaround, you can call 'Run > Inspect' on the variable with incomplete children. When called on a selection in the variables view, the result (including children) appears in the Expressions view. When called on a selection in the editor, the result appears in a lightweight popup, which can quickly be dismissed with the 'Esc' key.
This requires a non-trivial amount of work to fix, and was discovered too late to fix in 3.1. We will target 3.1.1.
Created attachment 24399 [details] RemoteTreeViewer patch added code to override default behavior where findItem(..) is called. Substituted with a new findItems(..) method, then iterated through the returned items. Patch appears to solve the problem. Will run with the code for a little while before releasing.
*** Bug 58768 has been marked as a duplicate of this bug. ***
Created attachment 24427 [details] cleaned up patch
committed patch to R3_1_maintenance and HEAD.
Darin, please verify.
Verified in HEAD. Found a problem with restoration of recursive data structures (but confirmed the problem also occurrs in the 3.1 code base - will file a new bug for that).
Verified in 3.1 maintenance stream.
*** Bug 104982 has been marked as a duplicate of this bug. ***
Re-opening. The fix only works for the top level elements. However, the secondary elements do not work properly. In this test case (from original bug report), only the top level t1 and t2 show duplicate children, but the inst var fName does not show duplicate children properly.
Created attachment 25303 [details] example problem Problem does not appear to be consistent - sometimes it works, sometimes does not. Screenshot shows problem.
Problem appears related to auto expansion (restoration of expansion state). When I manually expand, all works well.
I see the problem with manual expansion also. I also notice that changing the expansion of t1.fName manually sometimes affects the expansion of t2.fName when it should have no impact.
Fixed. Problem was in replace(...) code in remote tree viewer. When replacing children for a parent, if the number of new children is > number of old children, we simply do an 'add(parent, children)' on the remaining children. However, this added to the other (duplicate) parent. Instead, an 'internalAdd (...)' on the specific widget should be performed. The replace code already loops thru all parents, so children will be added to all parents. Changes to RemoteTreeViewer.
Released fix to 3.1.1 and 3.2. Please verify, Kevin.
verified
*** Bug 106082 has been marked as a duplicate of this bug. ***
*** Bug 108976 has been marked as a duplicate of this bug. ***
*** Bug 109995 has been marked as a duplicate of this bug. ***
