|
|
| Re: Execute Command without stacking on CommandStack [message #1151469 is a reply to message #1151281] |
Wed, 23 October 2013 11:19   |
 Felix Dorner
Messages: 295
Registered: March 2012 |
Senior Member |
|
|
On 23/10/2013 10:36, Erik Schondorff wrote:
> But now I want to set a property, but which is not undoable, so will not
> be stacked on the CommandStack. Thought, eSet in the innermost run()
> method could work, but runs in same exception as the first. How I can
> reach my aim?
This works for me, but I don't know if it's all technically correct, or
if there's a simpler way. Christian will probably answer soon :)
TransactionImpl t = new TransactionImpl(editingDomain, false,
Collections.EMPTY_MAP);
t.start();
Command c = SetCommand.create(...);
if (c.canExecute()){
c.execute();
}
try {
t.commit();
} catch (RollbackException exception_p) {
// ...
}
Felix
|
|
|
| Re: Execute Command without stacking on CommandStack [message #1151538 is a reply to message #1151469] |
Wed, 23 October 2013 12:16 |
|
Hi, Felix,
Yes, that works, but I'm a bit concerned about the statement that the
change should not be undoable. Does this command alter objects that
were modified by commands that are on the stack? If so, undoing them
would no longer work and the stack had better be flushed to avoid
potential damage.
The TransactionalCommandStack has a variant of the execute method that
accepts transaction options: passing the NO_REDO option would let the
command-stack execute the command as usual but, because it would not be
undoable, the stack would not be canUndo() and hopefully would flush
itself. But, I don't know whether it works this way ... it is all so
long ago.
HTH
Christian
On 2013-10-23 11:19:37 +0000, Felix Dorner said:
> On 23/10/2013 10:36, Erik Schondorff wrote:
>> But now I want to set a property, but which is not undoable, so will not
>> be stacked on the CommandStack. Thought, eSet in the innermost run()
>> method could work, but runs in same exception as the first. How I can
>> reach my aim?
>
> This works for me, but I don't know if it's all technically correct, or
> if there's a simpler way. Christian will probably answer soon :)
>
> TransactionImpl t = new TransactionImpl(editingDomain, false,
> Collections.EMPTY_MAP);
> t.start();
> Command c = SetCommand.create(...);
> if (c.canExecute()){
> c.execute();
> }
> try {
> t.commit();
> } catch (RollbackException exception_p) {
> // ...
> }
>
> Felix
|
|
|
|
| Re: Execute Command without stacking on CommandStack [message #1151624 is a reply to message #1151544] |
Wed, 23 October 2013 13:31 |
Felix Dorner
Messages: 295
Registered: March 2012 |
Senior Member |
|
|
You need to make sure you understand the different transaction contexts,
that is none, read, read/write. Read once through the EMF Transaction
documentation, it is very good and not too complex.
Your code executes inside the call stack of a post-commit listener,
which is always in a readOnly context. It's not possible to modify the
model here.
Instead, you should put your model changing code in a
NotificationPreCommitListener, and register it somehow with the
DiagramEventBroker. Maybe the GMF group can also help, I have only a
very basic idea about that stuff.
On 23/10/2013 14:25, Erik Schondorff wrote:
> java.lang.IllegalStateException: Cannot activate read/write transaction
> in read-only transaction context
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.acquire(TransactionalEditingDomainImpl.java:576)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.activate(TransactionalEditingDomainImpl.java:508)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.start(TransactionImpl.java:204)
>
> at
> org.eclipse.papyrus.commands.NotifyingWorkspaceCommandStack.createTransaction(NotifyingWorkspaceCommandStack.java:394)
>
> at
> org.eclipse.emf.workspace.EMFCommandOperation.createTransaction(EMFCommandOperation.java:215)
>
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:147)
>
> at
> org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:513)
>
> at
> org.eclipse.papyrus.commands.CheckedOperationHistory.execute(CheckedOperationHistory.java:182)
>
> at
> org.eclipse.papyrus.commands.NotifyingWorkspaceCommandStack.doExecute(NotifyingWorkspaceCommandStack.java:252)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
>
> at
> de.vw.ag.papyrus.swat.diagram.edit.parts.Anforderung2EditPart.handleNotificationEvent(Anforderung2EditPart.java:132)
>
> at
> org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart.notifyChanged(GraphicalEditPart.java:1438)
>
> at
> org.eclipse.gmf.runtime.diagram.core.listener.DiagramEventBroker.fireNotification(DiagramEventBroker.java:500)
>
> at
> org.eclipse.gmf.runtime.diagram.core.listener.DiagramEventBroker.resourceSetChanged(DiagramEventBroker.java:395)
>
> at
> org.eclipse.gmf.runtime.diagram.ui.DiagramEventBrokerThreadSafe.resourceSetChanged(DiagramEventBrokerThreadSafe.java:73)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl$1.run(TransactionalEditingDomainImpl.java:781)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.runExclusive(TransactionalEditingDomainImpl.java:328)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.postcommit(TransactionalEditingDomainImpl.java:771)
>
|
|
|
Powered by
FUDForum. Page generated in 0.02005 seconds
Search
Help
Register
Login
Home
