Community
Participate
Working Groups
When executing, undoing or redoing an operation the history should check if the operation can still be undone or redone. If not the stack should be flushed instead of adding a not executable operation to it.
Affected methods: exeute, doUndo, doRedo.
In the current implementation: - on execute, the history checks whether the operation can be executed. If it cannot, it is not added to the history and an ERROR status (INVALID OPERATION) is reported. - on undo and redo, the operation is already in the history. The history checks whether the operation canXxx. If it cannot, an ERROR status (INVALID OPERATION) is reported and the operation is removed from the history. - on add, the operation is assumed to have already been executed, so no checks are performed. When an invalid operation is discovered, we don't flush in the framework because we don't assume that all other operations are invalid. We leave the "aggressiveness" of maintaining the history up to the application. The action handlers DO flush when the error status is returned. Please advise how this is different than you were expecting. (Note: there was a bug in execute() in the open composite case where the invalid check was not done. Perhaps that is what you saw that triggered this bug?)
I am talking about the reverse operation. For example: after successfully executing an operation the history can check if the operation can be undone. If not the history shouldn't add the operation to the undo stack since undoing it will not be possible in the future. Same for doUndo and doRedo. I agree that flushing the stack is too aggressive here.
Since the canXxxx methods are fast, I don't see a problem with adding this conservatism. The execute, doUndo, and doRedo methods have been updated for the 0209 IBuild. The spec for execute on IOperationHistory will not be updated since we do not want to encourage clients to execute operations that cannot be undone. I will keep the existing language that says "if successful, the operation will be added to the history."
This was implemented for M5 but keeping this bug open until refactoring integration is complete and tested during M6 cycle.
this bug has been fixed in M6 cycle.
verified on I20050330-0500
