Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Transaction.OPTION_NO_UNDO
| Transaction.OPTION_NO_UNDO [message #129719] |
Wed, 17 September 2008 09:26  |
Eclipse User |
|
|
|
Originally posted by: andreas-scharf.gmx.de
Hi,
I wrote an action whic the user can call within a view (not an editor).
The action modifies some resources (i.e. it deletes objects) and then
I've to save the resources that were affected automatically. I don't
want the user to undo these changes in any opened editor, so I did this:
editingDomain.getCommandStack().execute(
DeleteCommand.create(editingDomain, preparedSelection),
Collections.singletonMap(Transaction.OPTION_NO_UNDO, Boolean.TRUE));
The problem is, that my editor still get's dirty and enables the undo
action. That's fatal because the user then presses undo, the editor
isn't dirty anymore but the resource doesn't get saved (since save was
not included in the deleteCommand of course).
Do I have to manually react in my editor on this transaction flag which
I've set above and don't let the editor get dirty? I thought that would
automatically handled by not notifiying any IOperationHistoryListeners.
I should mention that I'm using the WorkspaceCommandStack.
Regards,
Andreas
|
|
|
| Re: Transaction.OPTION_NO_UNDO [message #129733 is a reply to message #129719] |
Wed, 17 September 2008 12:46  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Andreas,
This option simply instructs the transaction not to record undo
information, and should generally be used only when there is no need to
record it because you already have the undo information in hand. This
is the case, for example, in the transactions that are used for undoing
and redoing Commands (including RecordingCommands) on a CommandStack or
IUndoableOperations (including AbstractEMFOperations) on the
IOperationHistory.
Perhaps it makes sense that the operation created by the
WorkspaceCommandStack to wrap the command should not be undoable() if
this option was supplied. I am only concerned that it is a change in
the semantics (from "just don't record undo information" to "these
changes are not undoable). Perhaps you can raise an enhancement
request, for addition of a new option? It may be called EXECUTE_ONLY or
NOT_UNDOABLE. Suggestions for an option name are welcome.
Cheers,
Christian
Andreas Scharf wrote:
> Hi,
>
> I wrote an action whic the user can call within a view (not an editor).
> The action modifies some resources (i.e. it deletes objects) and then
> I've to save the resources that were affected automatically. I don't
> want the user to undo these changes in any opened editor, so I did this:
>
> editingDomain.getCommandStack().execute(
> DeleteCommand.create(editingDomain, preparedSelection),
> Collections.singletonMap(Transaction.OPTION_NO_UNDO, Boolean.TRUE));
>
> The problem is, that my editor still get's dirty and enables the undo
> action. That's fatal because the user then presses undo, the editor
> isn't dirty anymore but the resource doesn't get saved (since save was
> not included in the deleteCommand of course).
>
> Do I have to manually react in my editor on this transaction flag which
> I've set above and don't let the editor get dirty? I thought that would
> automatically handled by not notifiying any IOperationHistoryListeners.
> I should mention that I'm using the WorkspaceCommandStack.
>
> Regards,
> Andreas
|
|
|
| Re: Transaction.OPTION_NO_UNDO [message #129745 is a reply to message #129733] |
Thu, 18 September 2008 13:19 |
| Eclipse User |
|
|
|
Originally posted by: andreas-scharf.gmx.de
Christian,
that would be very great ;). I solved it by creating a command which is
undoable which is of course the same as an operation which is undoable.
However such an option would be very helpful and NOT_UNDOABLE sounds good.
Cheers,
Andreas
Christian W. Damus schrieb:
> Hi, Andreas,
>
> This option simply instructs the transaction not to record undo
> information, and should generally be used only when there is no need to
> record it because you already have the undo information in hand. This
> is the case, for example, in the transactions that are used for undoing
> and redoing Commands (including RecordingCommands) on a CommandStack or
> IUndoableOperations (including AbstractEMFOperations) on the
> IOperationHistory.
>
> Perhaps it makes sense that the operation created by the
> WorkspaceCommandStack to wrap the command should not be undoable() if
> this option was supplied. I am only concerned that it is a change in
> the semantics (from "just don't record undo information" to "these
> changes are not undoable). Perhaps you can raise an enhancement
> request, for addition of a new option? It may be called EXECUTE_ONLY or
> NOT_UNDOABLE. Suggestions for an option name are welcome.
>
> Cheers,
>
> Christian
>
> Andreas Scharf wrote:
>> Hi,
>>
>> I wrote an action whic the user can call within a view (not an
>> editor). The action modifies some resources (i.e. it deletes objects)
>> and then I've to save the resources that were affected automatically.
>> I don't
>> want the user to undo these changes in any opened editor, so I did this:
>>
>> editingDomain.getCommandStack().execute(
>> DeleteCommand.create(editingDomain, preparedSelection),
>> Collections.singletonMap(Transaction.OPTION_NO_UNDO, Boolean.TRUE));
>>
>> The problem is, that my editor still get's dirty and enables the undo
>> action. That's fatal because the user then presses undo, the editor
>> isn't dirty anymore but the resource doesn't get saved (since save was
>> not included in the deleteCommand of course).
>>
>> Do I have to manually react in my editor on this transaction flag
>> which I've set above and don't let the editor get dirty? I thought
>> that would automatically handled by not notifiying any
>> IOperationHistoryListeners.
>> I should mention that I'm using the WorkspaceCommandStack.
>>
>> Regards,
>> Andreas
|
|
|
| Re: Transaction.OPTION_NO_UNDO [message #620313 is a reply to message #129719] |
Wed, 17 September 2008 12:46 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Andreas,
This option simply instructs the transaction not to record undo
information, and should generally be used only when there is no need to
record it because you already have the undo information in hand. This
is the case, for example, in the transactions that are used for undoing
and redoing Commands (including RecordingCommands) on a CommandStack or
IUndoableOperations (including AbstractEMFOperations) on the
IOperationHistory.
Perhaps it makes sense that the operation created by the
WorkspaceCommandStack to wrap the command should not be undoable() if
this option was supplied. I am only concerned that it is a change in
the semantics (from "just don't record undo information" to "these
changes are not undoable). Perhaps you can raise an enhancement
request, for addition of a new option? It may be called EXECUTE_ONLY or
NOT_UNDOABLE. Suggestions for an option name are welcome.
Cheers,
Christian
Andreas Scharf wrote:
> Hi,
>
> I wrote an action whic the user can call within a view (not an editor).
> The action modifies some resources (i.e. it deletes objects) and then
> I've to save the resources that were affected automatically. I don't
> want the user to undo these changes in any opened editor, so I did this:
>
> editingDomain.getCommandStack().execute(
> DeleteCommand.create(editingDomain, preparedSelection),
> Collections.singletonMap(Transaction.OPTION_NO_UNDO, Boolean.TRUE));
>
> The problem is, that my editor still get's dirty and enables the undo
> action. That's fatal because the user then presses undo, the editor
> isn't dirty anymore but the resource doesn't get saved (since save was
> not included in the deleteCommand of course).
>
> Do I have to manually react in my editor on this transaction flag which
> I've set above and don't let the editor get dirty? I thought that would
> automatically handled by not notifiying any IOperationHistoryListeners.
> I should mention that I'm using the WorkspaceCommandStack.
>
> Regards,
> Andreas
|
|
|
| Re: Transaction.OPTION_NO_UNDO [message #620314 is a reply to message #129733] |
Thu, 18 September 2008 13:19 |
 Andreas Scharf
Messages: 20
Registered: September 2010 |
Junior Member |
|
|
Christian,
that would be very great ;). I solved it by creating a command which is
undoable which is of course the same as an operation which is undoable.
However such an option would be very helpful and NOT_UNDOABLE sounds good.
Cheers,
Andreas
Christian W. Damus schrieb:
> Hi, Andreas,
>
> This option simply instructs the transaction not to record undo
> information, and should generally be used only when there is no need to
> record it because you already have the undo information in hand. This
> is the case, for example, in the transactions that are used for undoing
> and redoing Commands (including RecordingCommands) on a CommandStack or
> IUndoableOperations (including AbstractEMFOperations) on the
> IOperationHistory.
>
> Perhaps it makes sense that the operation created by the
> WorkspaceCommandStack to wrap the command should not be undoable() if
> this option was supplied. I am only concerned that it is a change in
> the semantics (from "just don't record undo information" to "these
> changes are not undoable). Perhaps you can raise an enhancement
> request, for addition of a new option? It may be called EXECUTE_ONLY or
> NOT_UNDOABLE. Suggestions for an option name are welcome.
>
> Cheers,
>
> Christian
>
> Andreas Scharf wrote:
>> Hi,
>>
>> I wrote an action whic the user can call within a view (not an
>> editor). The action modifies some resources (i.e. it deletes objects)
>> and then I've to save the resources that were affected automatically.
>> I don't
>> want the user to undo these changes in any opened editor, so I did this:
>>
>> editingDomain.getCommandStack().execute(
>> DeleteCommand.create(editingDomain, preparedSelection),
>> Collections.singletonMap(Transaction.OPTION_NO_UNDO, Boolean.TRUE));
>>
>> The problem is, that my editor still get's dirty and enables the undo
>> action. That's fatal because the user then presses undo, the editor
>> isn't dirty anymore but the resource doesn't get saved (since save was
>> not included in the deleteCommand of course).
>>
>> Do I have to manually react in my editor on this transaction flag
>> which I've set above and don't let the editor get dirty? I thought
>> that would automatically handled by not notifiying any
>> IOperationHistoryListeners.
>> I should mention that I'm using the WorkspaceCommandStack.
>>
>> Regards,
>> Andreas
|
|
|
Goto Forum:
Current Time: Thu Apr 18 04:36:59 GMT 2024
Powered by FUDForum. Page generated in 0.01965 seconds |
] 
Search
Help
Register
Login
Home
