Bugzilla – Full Text Bug Listing
| Summary: | checking canRedo() for wrapped GEF commands | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Christian Vogt <cvogt> | ||||||||||
| Component: | General | Assignee: | Alex Boyko <aboyko> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | schafe | ||||||||||
| Version: | unspecified | Keywords: | contributed | ||||||||||
| Target Milestone: | 1.0.1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 48410 [details]
possible fix - attempt 1
Here is a possible fix with the utility method that checks whether commands wrapped inside the GEF command (or GMF command derived from GEF command) are redoable, i.e. a way to determine redoability correctly for GEF CompoundCommand and GMF IProxyCommand (a GEF-type wrapper for GMF command).
Utility is used in DeferredCreateConnectionViewAndElementCommand #canRedo method.
Utility should also be used in CommandProxy.canRedo() Created attachment 48419 [details]
possible fix - CommandProxy also uses utility
Added utility usage for CommandProxy.canRedo() as suggested.
Created attachment 48453 [details]
update
Noticed that to check GEF's command redoability a canUndo() should be called instead of canExecute
Reviewed by Mohammed, commited by Cherie. Marking as fixed. The utility hasn't been applied to CreateViewAndOptionallyElementCommand #canRedo() method. Created attachment 50513 [details]
patch for CreateViewAndOptionallyElementCommand
the patch for the command to which the utility hasn't been applied
Commited for 1.0.1 - marking as fixed [GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug |
In my scenario when DeferredCreateConnectionViewAndElementCommand.canRedo() is called, the wrapped GEF command has the following general structure: CompoundCommand - ICommandProxy - CompositeCommand - SemanticCreateCommand - Subclass of CreateRelationshipCommand For CreateRelationshipCommand canExecute() returns false because the target of the relationship does not exist until part of the operation (not shown in the above structure) were to be redone first, but canRedo() returns true. The command should be redoable but this is not happening. Checking whether the wrapped command can be executed does not mean that it can be redone, or viseversa. The wrapped command may be a composite command N levels deep, and within this tree of commands are IUndoableOperations which provide a canRedo() method. For these commands canRedo() may return true and canExecute() return false. There seems to be many areas where GEF commands are being wrapped and canRedo is handled differently (eg.CommandProxy checks if the wrapped command can be Undone to allow redo). By looking at org.eclipse.gef.commands.CommandStack.canRedo(), it would seem that GEF assumes that any command that is undoable is also redoable, because CommandStack.canRedo() returns true if a command is on the redoable stack. Perhaps a utility to travel the compound, composite, and standard wrapper commands could be utilized to check if the command is redoable.