|
Re: rolling back model changes [message #1092897 is a reply to message #1082927] |
Fri, 23 August 2013 09:51 |
Felix Velasco Messages: 43 Registered: July 2009 |
Member |
|
|
If I understand you right, your feature does some changes, then gets canceled by the user, and you return false in the hasDoneChanges() method? If so, I doubt this ever worked.
The hasDoneChanges() method is used to determine whether to put the command in undo/redo stack, and has no effect on the command execution. If you want to cancel an already running feature, and want the framework to undo your changes, you must throw an OperationCanceledException, and then Graphiti (EMF transaction really) will undo the changes for you.
This has the collateral effect that an info log entry will be created in the error log (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=411129), but hopefully that soon will be optional.
|
|
|
Re: rolling back model changes [message #1092905 is a reply to message #1082927] |
Fri, 23 August 2013 10:03 |
Felix Velasco Messages: 43 Registered: July 2009 |
Member |
|
|
If I understand you right, your feature does some changes, then gets canceled by the user, and you return false in the hasDoneChanges() method? If so, I doubt this ever worked.
The hasDoneChanges() method is used to determine whether to put the command in undo/redo stack, and has no effect on the command execution. If you want to cancel an already running feature, and want the framework to undo your changes, you must throw an OperationCanceledException, and then Graphiti (EMF transaction really) will undo the changes for you.
This has the collateral effect that an info log entry will be created in the error log (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=411129), but hopefully that soon will be optional.
|
|
|
Re: rolling back model changes [message #1092906 is a reply to message #1082927] |
Fri, 23 August 2013 10:04 |
Felix Velasco Messages: 43 Registered: July 2009 |
Member |
|
|
If I understand you right, your feature does some changes, then gets canceled by the user, and you return false in the hasDoneChanges() method? If so, I doubt this ever worked.
The hasDoneChanges() method is used to determine whether to put the command in undo/redo stack, and has no effect on the command execution. If you want to cancel an already running feature, and want the framework to undo your changes, you must throw an OperationCanceledException, and then Graphiti (EMF transaction really) will undo the changes for you.
This has the collateral effect that an info log entry will be created in the error log (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=411129), but hopefully that soon will be optional.
|
|
|
Re: rolling back model changes [message #1093765 is a reply to message #1092906] |
Sat, 24 August 2013 16:30 |
|
Hi Henrik,
We are doing exactly the same thing in the eclipse BPMN2 Modeler project (i.e. using a modal dialog for configuring model elements). Since submitting this feature request, I've rethought some of this behavior and have found the best way to handle this is to create a nested transaction within the dialog. Have a look at the AbstractObjectEditingDialog class in the BPMN2 Modeler git repository.
HTH,
Bob
|
|
|
Powered by
FUDForum. Page generated in 0.03551 seconds