|
|
Re: TransactionalEditingDomain with Eclipse's IOperationHistory [message #1245218 is a reply to message #1245126] |
Thu, 13 February 2014 13:22 |
|
Hi, Erdal,
It's more than a bit surprising that undo should happen in parallel.
Are you quite sure that operations are being undone actually in
parallel? I think it's more likely that somehow, because the undo is
happening on the UI thread, the job-manager-aware ILock implementation
that the TransactionalEditingDomain uses for synchronization triggers
nested UI event loops to keep the UI responsive, and these are picking
up Ctrl+Z keystrokes and performing nested (not parallel) undos.
The end result would be just as destructive to your models. But I'd
also be surprised that the operation history allows nested undo/redo
requests.
In any case, there's no way that your application should have to ensure
that commands are undone serially by queuing them. If the editing
domain is doing something that causes this behaviour (which I think
must be the case), it behooves the editing domain to do what it takes
to ensure serial execution of undo/redo.
Cheers,
Christian
On 2014-02-13 10:30:35 +0000, Erdal Karaca said:
> Coordinating consecutive calls to UNDO/REDO using a queue seems to
> work... Though, if you have a better idea, let me know :)
|
|
|
Re: TransactionalEditingDomain with Eclipse's IOperationHistory [message #1245235 is a reply to message #1245218] |
Thu, 13 February 2014 13:56 |
Erdal Karaca Messages: 854 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks, you are absolutely right: there are nested calls (triggered inside command execution) rather than parallel executions.
Though, as said, it is sufficient to make the undo/redo handlers aware of nested undo/redo calls.
Christian W. Damus wrote on Thu, 13 February 2014 14:22Hi, Erdal,
It's more than a bit surprising that undo should happen in parallel.
Are you quite sure that operations are being undone actually in
parallel? I think it's more likely that somehow, because the undo is
happening on the UI thread, the job-manager-aware ILock implementation
that the TransactionalEditingDomain uses for synchronization triggers
nested UI event loops to keep the UI responsive, and these are picking
up Ctrl+Z keystrokes and performing nested (not parallel) undos.
The end result would be just as destructive to your models. But I'd
also be surprised that the operation history allows nested undo/redo
requests.
In any case, there's no way that your application should have to ensure
that commands are undone serially by queuing them. If the editing
domain is doing something that causes this behaviour (which I think
must be the case), it behooves the editing domain to do what it takes
to ensure serial execution of undo/redo.
Cheers,
Christian
On 2014-02-13 10:30:35 +0000, Erdal Karaca said:
> Coordinating consecutive calls to UNDO/REDO using a queue seems to
> work... Though, if you have a better idea, let me know
|
|
|
Powered by
FUDForum. Page generated in 0.03522 seconds