Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Different behavior between undo and redo
Different behavior between undo and redo [message #1734461] Wed, 08 June 2016 14:18 Go to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 44
Registered: June 2015
Member
Hi all,

I made the following test. I import the Graphiti tutorial example and change TutorialRenameEClassFeature to implement ICustomUndoRedoFeature.
I simply return false in the canRedo method.

From there, I launch the application, create a diagram, add a new class and change its name. I can undo the renaming. TutorialRenameEClassFeature.canUndo is called and returns true.

But... I can also perform a redo ! And TutorialRenameEClassFeature.canRedo is not called until the redo actually takes place.

Before the undo is proposed in the context menu to the user, canUndo is called to check whether the undo can take place. And, during undo execution, canUndo is called once again to check whether the feature pre/postUndo methods have to be executed (see GFWorkspaceCommandStackImpl.undo()).

In a redo situation, canRedo is not called to check whether the redo should actually take place. Only during redo execution will it be called to check whether the feature pre/postRedo methods have to be executed.

In other words, there is no way to prevent the EMF redo to take place.

GFWorkspaceCommandStackImpl.canUndo execution leads to TutorialRenameEClassFeature.canUndo call.
Whereas GFWorkspaceCommandStackImpl.canRedo does not...

This is due to a slight difference in GFPreparableCommand2 between canUndo and canRedo.
GFPreparableCommand2.canUndo overrides the default behavior as follow:
@Override
public boolean canUndo() {
	return getCommand().canUndo() && super.canUndo();
}

getCommand().canUndo() causes the feature canUndo to be called while super.canUndo() checks EMF RecordingCommand.canApplyChange().

There is no override for the parent class RecordingCommand.canRedo which only calls canApplyChange()...

Adding getCommand().canRedo() is not possible as getCommand() returns a Graphiti EmfOnGefCommand class that implements EMF Command interface and not the ConditionalRedoCommand one.

From what I've seen (to be confirmed), changing this in Graphiti internals is not straightforward and has impacts in several places.

Therefore, to have the feature canRedo being called to check if redo can take place, I suggest to override canRedo in GFWorkspaceCommandStackImpl as follow :
/**
 * Make sure canRedo is called for features implementing ICustomUndoRedoFeature.
 */
@Override
public boolean canRedo() {
	Command redoCmd = getRedoCommand();
	if (redoCmd != null && redoCmd instanceof GFPreparableCommand2) {
		Command wrappedCmd = ((GFPreparableCommand2) redoCmd).getCommand();
		if (wrappedCmd != null && wrappedCmd instanceof EmfOnGefCommand) {
			org.eclipse.gef.commands.Command innerCmd = ((EmfOnGefCommand) wrappedCmd).getGefCommand();
			if (innerCmd != null && innerCmd instanceof GefCommandWrapper) {
				ICommand cmd = ((GefCommandWrapper) innerCmd).getCommand();
				if (cmd != null && cmd instanceof GenericFeatureCommandWithContext) {
					IFeature feature = ((GenericFeatureCommandWithContext) cmd).getFeature();
					IContext context = ((GenericFeatureCommandWithContext) cmd).getContext();
					if (feature instanceof ICustomUndoRedoFeature)
						return ((ICustomUndoRedoFeature) feature).canRedo(context) && super.canRedo();
				}
			}
		}
	}

	return super.canRedo();
}

Kind regards,

Laurent

[Updated on: Wed, 08 June 2016 14:22]

Report message to a moderator

Re: Different behavior between undo and redo [message #1734526 is a reply to message #1734461] Thu, 09 June 2016 07:36 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1894
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Laurent,

hm, seems nobody ever tried to disable redo without disabling undo as well...

Thanks for the detailed analysis of this. Would you please file this as a bug against Graphiti including your code proposal.

Thanks,
Michael
Re: Different behavior between undo and redo [message #1734529 is a reply to message #1734526] Thu, 09 June 2016 08:13 Go to previous message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 44
Registered: June 2015
Member
Hi Michael,

It's done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=495769
And I agree, it is a specific situation. Typically when the feature canUndo and canRedo check whether an underlying business object is still existing.
It may have been removed after undo and before a redo is requested...

Regards,

Laurent
Previous Topic:Custom DiagramEditor
Next Topic:Load user image at runtime
Goto Forum:
  


Current Time: Mon Jun 25 10:17:08 GMT 2018

Powered by FUDForum. Page generated in 0.02102 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top