Bugzilla – Full Text Bug Listing
| Summary: | ChangeCommand: canUndo before execute always false | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Volker Stolz <stolz+bugzilla> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
A fix has been committed to CVS for 2.7. The fix is available in the latest build for the stream. |
Build Identifier: I20100608-0911 For the EMF ChangeCommand we have: public boolean canUndo() { return getChangeDescription() != null; } This means that a ChangeCommand will always return false for canUndo(), until you've actually executed the command. And, in the process, breaks embedding in the StrictCompoundCommand (unless you move it in the last position of the statement list, which is not easily possible for me). I think this violates the (not well documented) Command lifecycle, where generally commands can be checked for undoability before executing them. As the ChangeCommand is generally undoable, this method should always return true. Even in the face of an execution error, undo() will still handle an empty changeDescription gracefully. Also see the discussion in: http://www.eclipse.org/forums/index.php?t=msg&th=174332&start=0&S=fa2de84a45ec20c187e0cf3c1c3e98f9 A possible workaround is of course overloading canUndo() to always return true yourself. Reproducible: Always Steps to Reproduce: 1. ChangeCommand.canUndo() will always return false until the command has been executed.