Community
Participate
Working Groups
I20030930 Resource Navigator has sticky duplicate item after rename Steps: - create new workspace - in the Resource Navigator, create new simple project "prj" - create folder "folder" inside "prj" - create file "file.txt" inside "folder" - in the Resource Navigator, select file "file.txt" - choose menu File > Rename (or press F2) and change the name to "fool.txt" -> In "folder", I have two items "fool.txt" which both represent the same file. When I delete one of the tree items, the file is deleted from the filesystem. One of the tree items "fool.txt" inside "folder" stays there and can't be removed, not even by a refresh. It only goes away when I rename "folder" or restart eclipse. Note: the same problem seems to exist for *all* files and folders on the second level ("thing" inside a folder inside a project) Note2: this might be related to bug 44066.
Fix released for M4
*** Bug 41710 has been marked as a duplicate of this bug. ***
Reopened with comments from Nick (Kim please investigate if these are issues) - The old warning about processing removals before additions to avoid multiple equal elements is being ignored. Additions are now processed before removals, and the comment has been removed. - It turns redraw off and on, which will cause flicker since this always forces a complete redraw. - It does this even if there are no items to add. - The comment says it's doing this to avoid a flash showing both the old and new element, however the redraw is turned on before the removals are processed. Please ensure that the changes here: - avoids the problems with multiple equal elements in the viewers - doesn't cause any extra redraws, particularly for the common cases of elements changing, and single elements being added or removed.
It's been awhile, but this was the gist of our findings at the time. We found that when you processed removals first there was a refresh of the tree happening deep within the removal logic. This refresh was occuring when you tried to preserve the selection of the tree. This action actually caused the additions to be handled in the removal step because the input to the viewer was being refreshed in internalExpand(). When the additions were processed after removals this caused the duplicate element to be added twice. Your comment about the refresh is completely right, however. The calls to setRedraw() do seem unnecessary.
*** Bug 40214 has been marked as a duplicate of this bug. ***
Created attachment 6836 [details] Patch for org.eclipse.ui.ide Patch to clean up redraw issues. Only toggles redraw in the case of an addition and a deletion in the same delta.
Patch applied by Nick.
Patch applied. I tried doing the removes before the adds to try to reproduce the original problem. It did not end up calling the content provider's getChildren method. Tried both the case where the parent had been expanded, and where it had not. Of course, in the latter the element being removed wasn't in the selection, so it wouldn't try to expand the parent. In any case, remove should not try to preserve the selection for the removed elements (it should still preserve the rest of the selection, if any).
Filed bug 46852 [Viewers] remove should not try to preserve selection for removed elements.
Closed.
