Description Christian Vogt 2006-07-12 10:28:53 EDT

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.