Community
Participate
Working Groups
In Navagotor, Select the 'link with editor' button. Then open a file (FileICareAbout.java). (double click) then select a different file (StupidCroft.java) (single click) then right click and say delete, or move, or hit the delete key. it will prompt you for - are you sure you want to delete (StupidCroft.java) say yes. it will instead delete (FileICareAbout.java). also, undo will not be allowed.so you have to do some localhistory to revieve what you lost. much easier if you know which file you actually deleted)
I cannot reproduce this in M8 using a clean workspace and following the the steps above. Can you provide more detailed instructions? Is there anything in the .log file?
I failed to reproduce this problem as well. Is the project under source code control? Can you reproduce this with a new project? This should be P1 if reproducible. Otherwise, need additional confirmations and additional info.
i can reproduce this on a fairly constant basis. a few things to check. I知 using the M8 release for windows. i have the navigator undocked in a separate window. i tend to have a lot of files open (over 5) the file i want to delete IS NOT OPEN. (i believe this is curial) and the link is on
I'm able to reproduce it. It's important that the Navigator be a detached view.
The problem is that the confirmation dialog is parented under the main window's shell, not the view's shell. When it is closed, the main window is activated, activating the editor (which was the last active part in the main window), which triggers a selection changed in the Navigator due to Link with Editor being on, which changes the selection in DeleteResourceAction. DeleteResourceAction asks itself for the selection again after the confirmation dialog, before doing the delete. DeleteResourceAction, and most of the Navigator actions, are given the shell at creation time.
I've released a fix whereby it only obtains the selection once, before bringing up the dialog, and uses that throughout the run. Need to check other SelectionListenerActions that may have the same problem.
Also fixed up CopyResourceAction (superclass of MoveResourceAction). This got released for the M9 candidate, I20040521-0010.
Created attachment 10927 [details] Patch to BaseSelectionListenerAction to defer selection change while action is running Attached a patch to BaseSelectionListenerAction which defers processing a selection change while the action is running. I'm holding off on releasing this for M9, but it should go in for RC1, after further testing with delete, copy, move and other actions.
Should also change these actions to take a workbench part, or workbench part site, instead of a shell, and change IWorkbenchPartSite.getShell() to return the correct shell for a detached view. This is requires some new API change though.
Jim, the proposed API change would involve adding a constructor taking an IWorkbenchPart, IWorkbenchPartSite, or IWorkbenchSite instead of a shell in most/all of the actions in org.eclipse.ui.ide/extensions/org.eclipse.ui.actions, and deprecated the existing constructors. Probably best to use IWorkbenchSite so that IPage objects can use the actions too. When the shell is needed by the action, it would be obtained from the site. PartSite.getShell() would be changed to get the shell from the PartPane's control, not the window.
should be 3.0 RC1 not 2.0 RC1
The patch in comment #8 has been released, which protects other SelectionListenerActions if they receive a setSelection during a run(). This eliminates the need to fix up other subclasses which query the selection more than once. This also reduces the need for new constructors on the actions. I've filed bug 64486 for this, to be addressed post 3.0. We'll have to live with the incorrect dialog parenting for detached views for 3.0.
Verified in I20040604-1600
