Community
Participate
Working Groups
I20060906-1200 If a file gets delete after adding/changing/removing a marker then the Undo and Redo actions are not updated and still show, e.g. Undo Add Task Redo Add Task Executing the undo or redo does nothing (no feedback, no .log entry) and the undo and redo menu text remains the same and enabled.
the operation knows it's invalid, but the action handlers are not refreshed to indicate this. A temporary (M2) solution is to have the operation call operationChanged when its validity state changes. But the real solution will come with bug #87494, which may or may not be ready for M2.
Fixed in HEAD >20060912. I think the proper solution for now is to implement IAdvancedUndoableOperation (and IAdvancedUndoableOperation2) so that validity is computed just before attempting to execute, undo, or redo the operation. This means the undo/redo actions will still be available in the menus, but the problem will be caught. So the scenario will be: - add/change/remove a marker - delete the file - undo/redo will still show "Undo Add Task" (or whatever was last done with markers) - attempt to undo the operation and you will get an error saying that the resource no longer exists. This is similar to how refactoring problems are discovered. For example, rename a method, then update the source file, then try to undo the method rename from the package explorer. The invalid state is discovered during the undo. The idea is that expensive validation is not done until the operation is attempted. This fix is not an interim solution. It will always be appropriate to compute the status of the operation just before trying it. In M3, we may add some periodic validity checking so that the stack is occasionally purged without the user trying to perform the operation (see bug #87494). If this is done, the user would never have the undo or redo operation available. Dani, are you comfortable with this level of validation since the problem is now caught and described?
Also note that the use case will be different in M3 because after deleting the file, "Undo delete file" would appear in the menu.
OK for me assuming that the dialog only comes one time and then the operation is removed from the stack and I can undo the next operation.
Dialog only comes up once. Operation is removed from stack, .... but.... Once the top operation is invalidated, the entire workbench undo context is invalidated. This is a conservative, workbench-wide policy until we are sure we can be smarter about validation. It does not affect the undo stack (if any) of the editor on that file.
verified in I20060919-0010, WinXP, with these scenarios: - add a task to foo.java using the ruler - delete foo.java - try to "Undo Add Task" - warning dialog says that undo cannot be completed because marker no longer exists. - add a task to foo.java from the navigator edit menu (task with no location) - delete foo.java - try to "Undo Add Task" - warning dialog says that undo cannot be completed because marker no longer exists. - add a task to foo.java from foo.java's Edit... menu - delete foo.java - try to "Undo Add Task" - warning dialog says that undo cannot be completed because marker no longer exists. also each of these scenarios where the add task is followed by a delete task before deleting the resource. In this case, the "Undo Delete Task" has the same dialog when attempting it after deleting the resource. also each of these scenarios where the add task is followed by an edit on the task's name. In this case the "Undo Modify Task" has the same dialog when attempting it after deleting the resource.
