Community
Participate
Working Groups
On 0519 build, I was performing a "check out as project" while I had a dirty JUnit test case in 2 different Workbench Windows. I was prompted to save the same resource twice.
Not sure how CVS support does this. If it just calls the workbench save, reassign back to UI.
F2 - Also happens when performing Synchronize.
See CVSAction.saveAllEditors(). We loop over all open workbench windows, then loop over all workbench pages in the windows, calling the Workbench saveAllEditors(boolean) API. Is there a better recommended way to accomplish this? We have no idea what's in the editors, hence we don't know if there is a duplicate. Moving back to UI for comment.
This also happens during compile. While it is true that the Editor may open more than one file, can the workbench assume that two editors with the same EditorInput therefore operate on the same set of resource? Or perhaps validateEdit can be used to track exactly which resources the Editor is working with. Hope you don't mind Nick, but I changed this to LATER.
Reopened for investigation
*** Bug 64742 has been marked as a duplicate of this bug. ***
This also occurs when trying to replace an editor with the latest from HEAD, for example. The editor appears twice in the dirty list. There seems to be a general problem here with collecting dirty editors from multiple windows without removing duplicates.
*** Bug 94297 has been marked as a duplicate of this bug. ***
Moving Dougs bugs
Created attachment 53522 [details] Fix to SaveablesList reference counting In 3.2, you're prompted to save the same resource multiple times if there are multiple editors referencing it. There seem to be a couple of causes underlying this. Firstly, SaveablesList maintains a reference count of open Saveables, but gets the count wrong if the Saveables are equal (ie when saveable1.equals(saveable2) you would expect the reference count to go to 2 when 2 editors are open, but it only goes to 1. When both editors are closed the count goes to -1, etc). Secondly, this scheme would only work if the Saveables are equal when the underlying resource is the same, which isn't generally the case for DefaultSaveable as it just delegates .equals() to the EditorPart. Here's a very small patch which attempts to fix the reference count problem. I'm not sure of the best way to make Saveables equal, but for my RCP application I've just overridden equals and hashCode in the editor. Probably not the best way to do it though.
The patch looks reasonable but this area is very sensitive and I've never worked in it before. Deferring to Boris
Created attachment 53603 [details] Update with additional change to DefaultSaveable I've thought about this some more and think overriding equals in the Editor was a really bad idea. This patch combines my first patch with another possible approach. It adds a check for IEditorPart in the DefaultSaveable and seems to partially fix the issue, at least for the standard Java editors. That said, this might not be an approach you would want to take, and the behavior when closing a WorkbenchWindow if two are open still isn't what I would expect. (That case is handled by code in EditorManager.java)
Thanks for your help. There is an open bug against JDT for the double prompting, see bug 131068. The reference counting bug should probably be fixed for 3.2.2.
Also see clients of IWorkbenchPage.getDirtyEditors(). Some of them already prune duplicate editor inputs, e.g. compare's CompareUIPlugin.getDirtyEditors() or jdt.ui's EditorUtility.getDirtyEditors(). Others however show all editors for equal inputs, e.g. ui.ide's IDE.saveAllEditors(IResource[], boolean) or debug.ui's SaveScopeResourcesHandler.getScopedDirtyEditors(IProject[])).
(In reply to comment #10) > ... > Firstly, SaveablesList maintains a reference count of open Saveables, but gets > the count wrong if the Saveables are equal (ie when saveable1.equals(saveable2) > you would expect the reference count to go to 2 when 2 editors are open, but it > only goes to 1. When both editors are closed the count goes to -1, etc). Jon, did you actually observe this, or is this based on reading the code? I just checked the code and don't see how the count can go to -1.
(In reply to comment #15) > (In reply to comment #10) > > ... > > Firstly, SaveablesList maintains a reference count of open Saveables, but gets > > the count wrong if the Saveables are equal (ie when saveable1.equals(saveable2) > > you would expect the reference count to go to 2 when 2 editors are open, but it > > only goes to 1. When both editors are closed the count goes to -1, etc). > > Jon, did you actually observe this, or is this based on reading the code? I > just checked the code and don't see how the count can go to -1. > (In reply to comment #15) > (In reply to comment #10) > > ... > > Firstly, SaveablesList maintains a reference count of open Saveables, but gets > > the count wrong if the Saveables are equal (ie when saveable1.equals(saveable2) > > you would expect the reference count to go to 2 when 2 editors are open, but it > > only goes to 1. When both editors are closed the count goes to -1, etc). > > Jon, did you actually observe this, or is this based on reading the code? I > just checked the code and don't see how the count can go to -1. > Boris, I did see it go to -1, but looking at it again, I think that this was caused by my code (the EditorInput was changing) and that I misunderstood the intention behind the modelsForSource. I think you're right, and the code as it stands is fine. Sorry if I've wasted your time on this. Jon
(In reply to comment #16) > Sorry if I've wasted your time on this. No problem at all, it is good to have people like you who look at the code and point to potential problems.
*** This bug has been marked as a duplicate of bug 131068 ***
