Home » Modeling » GMF (Graphical Modeling Framework) » Changes via PropertySheet and undo/redo
| |
| Re: Changes via PropertySheet and undo/redo [message #220227 is a reply to message #220081] |
Fri, 27 February 2009 15:01   |
Eclipse User |
|
|
|
Originally posted by: cayla_sha.gmx.net
Hello Alex,
after Javiers mail I tried the same in my editor and it doesn`t work,
too. Neither Ctrl+Z, nor Edit -> Undo works.
I use newest available Eclipse (3.4.1) with GMF SDK 2.1.2.
Any ideas what to do?
Julia
Alex Shatalin schrieb:
> Hello Javier,
>
> This is incorrect behaviour. I checked that on the current version of
> Ecore diagram and can confirm that it works (I can unto setting
> “abstract” property of EClass made in Properties view by pressing Ctrl+Z
> on diagram).
>
> -----------------
> Alex Shatalin
>
>
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220242 is a reply to message #220227] |
Fri, 27 February 2009 15:46 |
| Eclipse User |
|
|
|
Originally posted by: tobk42.gmx.de
Same here! Undo/Redo of the generated property sheets (.edit project)
works in the generated EMF model editor (.editor project), but not in
the GMF diagram editor (.diagram project). Did not notice this until
now, though, as I switched to my own property sheets some time ago. ^^;
Tobias
Cayla Sha schrieb:
> Hello Alex,
>
> after Javiers mail I tried the same in my editor and it doesn`t work,
> too. Neither Ctrl+Z, nor Edit -> Undo works.
>
> I use newest available Eclipse (3.4.1) with GMF SDK 2.1.2.
>
> Any ideas what to do?
>
> Julia
>
>
> Alex Shatalin schrieb:
>> Hello Javier,
>>
>> This is incorrect behaviour. I checked that on the current version of
>> Ecore diagram and can confirm that it works (I can unto setting
>> “abstract” property of EClass made in Properties view by pressing
>> Ctrl+Z on diagram).
>>
>> -----------------
>> Alex Shatalin
>>
>>
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220300 is a reply to message #220077] |
Sun, 01 March 2009 13:05 |
| Eclipse User |
|
|
|
Originally posted by: Erazerx.gmx.de
Hi Javier,
first to the other thread: I had solved the problem only for some custom
Clipboard Actions for the diagram editor. There i wrapped EMF commands
into GMF commands. To get undo / redo to work, i simply had to add a
"EditingDomainUndoContext".
I have the same problem for all changes made in the Propertys View. I
was trying to manipulate the Providers in the Edit-Code to create some
custom commands, since all commands that are responsible for setting the
attributes are created from the "createSetCommand(..)" methods in the
corresponding provider.
However, i tried to return some other commands there that implement the
"IUndoableOperation" Interface and add a "ResourceUndoContext" and a
"EditingDomainUndoContext", but i didn't get it to work. But i think
this could be the right way to do it and i was just doing something
wrong. Please let me know if you get it to work.
Arne
Javier Cardenete schrieb:
> Hello all,
>
> I've been working with GMF for some months now and I didn't realize of a
> problem until now. When I make any change on an element through the
> PropertySheetPage, afterwards the undo/redo actions don't notice such a
> change. It's happening with the Mindmap example and with some other
> simple examples I made on my own. Is it sth weird or is it normal behavior?
>
> Thanks
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220358 is a reply to message #220077] |
Mon, 02 March 2009 12:34 |
| Eclipse User |
|
|
|
Originally posted by: Erazerx.gmx.de
Hello,
i just got this to work by implementing some workaround. It may be not
the best way to do it, but it works. (And also a global undo / redo for
a integrated EMF Editor, what i have, works perfect).
First i changed the Undo / Redo behavior of the diagram editor to do
just the undo / redo on the command stack of the transactional editing
domain. That will make undo / redo for setting attributes in the
properties view available. But then there is no more undo / redo for
changes in the diagram like moving nodes.
To get that to work i attached a operation history listener to the
operation history of the diagram editor. This listener reacts on newly
added commands to the diagram command stack. Whenever it gets such a
event, it creates a EMF command and commits the command that was in
relationship with that event to the EMF command .
The "redo" und "undo" methods in the emf command are then redirecting
the undo and redo to call the method of the command, that was resolved
by the event. The "execute" method in the EMF command must not be
implemented, since the original command will be executed on the diagram
command stack.
In a nutshell:
- i only use undo / redo with the methods of the commandstack of the
transactional editingdomain (NOT the command stack of the diagram edit
domain)
- everything that is run in the command stack of the diagram edit domain
(what affects the operation history of the diagram editor) gets
"wrapped" into a emf command that will executed on the command stack of
the transactional editing domain
Arne
Javier Cardenete schrieb:
> Hello all,
>
> I've been working with GMF for some months now and I didn't realize of a
> problem until now. When I make any change on an element through the
> PropertySheetPage, afterwards the undo/redo actions don't notice such a
> change. It's happening with the Mindmap example and with some other
> simple examples I made on my own. Is it sth weird or is it normal behavior?
>
> Thanks
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220445 is a reply to message #220358] |
Tue, 03 March 2009 11:41 |
 Javier
Messages: 57
Registered: July 2009 |
Member |
|
|
Hello Arne,
Your workaround makes sense to me but I haven't been able to implement
it. I don't really know how to change the Undo / Redo behavior of an
editor. I've been trying to modify the default Undo/Redo actions by a
new ones, but it didn't work. Could you give me a hint for it?
Actually, my first goal was (and still is) to get a global Undo/Redo
actions for the whole editor (EMF & GMF). I followed the tutorial on how
to integrate both, and I was working on the unifying of Undo/Redo
actions when I noticed the problem of changes in the PropertySheet not
going to Undo/Redo in diagram. I implemented the
multipageActionbarContributor and the SubActionbars2. THere is were I
was trying to unify the actions, but it's not working so far. So right
now what I have is:
- Changes in PropertySheet only appear in Undo/Redo of the EMF Editor
(and not in Diagram) --> Solution: your workaround
- Changes in Diagram only appear in Undo/Redo of the Diagram Editor (and
not in the EMF Editor) --> Solution: I guess unifying actions.
- I implemented some Actions for the diagram Editor that change values
in the model, using AbstractTransactionalCommand. I had to add the
UndoContext of the DiagramEditor for those changes to be visible on the
Undo/Redo actions of the Diagram (but they still don't appear in the EMF
Editor --i guess because of the same as with direct modifications)
So if u could give me a hint on how to unify both editor's actions and a
little deeper explanation on this workaround, it'd be really helpful.
And apart from this, is this problem with the property sheet page a Bug?
Or there is something wrong in the definition models?
Thanks,
Javier.
Arne escribió:
> Hello,
>
> i just got this to work by implementing some workaround. It may be not
> the best way to do it, but it works. (And also a global undo / redo for
> a integrated EMF Editor, what i have, works perfect).
>
> First i changed the Undo / Redo behavior of the diagram editor to do
> just the undo / redo on the command stack of the transactional editing
> domain. That will make undo / redo for setting attributes in the
> properties view available. But then there is no more undo / redo for
> changes in the diagram like moving nodes.
>
> To get that to work i attached a operation history listener to the
> operation history of the diagram editor. This listener reacts on newly
> added commands to the diagram command stack. Whenever it gets such a
> event, it creates a EMF command and commits the command that was in
> relationship with that event to the EMF command .
>
> The "redo" und "undo" methods in the emf command are then redirecting
> the undo and redo to call the method of the command, that was resolved
> by the event. The "execute" method in the EMF command must not be
> implemented, since the original command will be executed on the diagram
> command stack.
>
> In a nutshell:
> - i only use undo / redo with the methods of the commandstack of the
> transactional editingdomain (NOT the command stack of the diagram edit
> domain)
> - everything that is run in the command stack of the diagram edit domain
> (what affects the operation history of the diagram editor) gets
> "wrapped" into a emf command that will executed on the command stack of
> the transactional editing domain
>
> Arne
>
> Javier Cardenete schrieb:
>> Hello all,
>>
>> I've been working with GMF for some months now and I didn't realize of a
>> problem until now. When I make any change on an element through the
>> PropertySheetPage, afterwards the undo/redo actions don't notice such a
>> change. It's happening with the Mindmap example and with some other
>> simple examples I made on my own. Is it sth weird or is it normal behavior?
>>
>> Thanks
|
|
| |
| Re: Changes via PropertySheet and undo/redo [message #220474 is a reply to message #220445] |
Tue, 03 March 2009 16:29 |
| Eclipse User |
|
|
|
Originally posted by: Erazerx.gmx.de
Hi,
i had the same situation as you with a ingetrated EMF editor. With this
you will have also all changes from the Diagram Editor in the EMF
Editor-Tab. I will give you code snippets how i did everything. You will
need to have one TransactionalEditingDomain for both Editor-Tabs to get
everything to work. I do not know if the non-existing undo / redo for
the property view is a bug. Also, i do not have the newest GMF version
since i have to work with Eclipse 3.3. But i hope this workaround also
works for you.
At first do the changes to redirect the GMF commands to the EMF Editing
domain's command stack:
In the Main Editor class (XXXDiagramEditor) override the
configureDiagramEditDomain Method:
------> changes in XXXDiagramEditor.java:
@Override
protected void configureDiagramEditDomain() {
super.configureDiagramEditDomain();
if (getOperationHistory() != null
&& getEditingDomain() != null) {
redirecter = new
RedirectToEmfCommandCommandListener(getEditingDomain());
getOperationHistory().addOperationHistoryListener(redirecter );
}
}
The RedirectToEmfCommandCommandListener wraps all commands that are
executed on the History into EMF commands and executes them on the EMF
command stack.
------> new Class: RedirectToEmfCommandCommandListener
public class RedirectToEmfCommandCommandListener implements
IOperationHistoryListener {
private TransactionalEditingDomain emfEdit;
public RedirectToEmfCommandCommandListener(TransactionalEditingDoma in
emfEdit) {
this.emfEdit = emfEdit;
}
public void historyNotification(OperationHistoryEvent event) {
if (emfEdit != null) {
// when operation has been added, wrap it into a emf command
if (event.getEventType() ==
OperationHistoryEvent.OPERATION_ADDED) {
GMFToEMFWrapper wrap = new GMFToEMFWrapper(emfEdit,
event.getOperation());
emfEdit.getCommandStack().execute(wrap);
}
}
}
/**
* Wrapper to wrap a GMF command into a EMF command
*
*/
public class GMFToEMFWrapper extends AbstractOverrideableCommand {
private IUndoableOperation operation;
protected GMFToEMFWrapper(EditingDomain domain, IUndoableOperation
command) {
super(domain);
this.operation = command;
}
@Override
public void doExecute() {
// no execution needed, execution has been done on diagram
// command stack
}
@Override
public void doRedo() {
try {
operation.redo(null, null);
}
catch (Throwable e) {
}
}
@Override
public void doUndo() {
if (operation != null) {
try {
operation.undo(null, null);
}
catch (Throwable e) {
}
}
}
@Override
public boolean doCanExecute() {
//just return true. nothing will be done on execution but it has
//to be done, to get it on the "EMF-Command Stack"
return true;
}
@Override
public boolean doCanUndo() {
if (operation != null) {
return operation.canUndo();
}
else {
return false;
}
}
@Override
public String doGetLabel() {
if (operation != null) {
return operation.getLabel();
}
else {
return "Diagram-Operation";
}
}
}
}
Now how to implement your own Undo / Redo:
In the same package as the class for the diagram editor, you have a
XXXXDiagramActionBarContributor. In this class, override the
init(IActionBars) method. (I have a slightliy different situation, but
it should work this way or at least gives you a idea how to do it)
------> XXXXDiagramActionBarContributor.java
private Action diagramUndoAction;
private Action diagramRedoAction;
@Override
public void init(IActionBars bars) {
super.init(bars);
ISharedImages sharedImages = PlatformUI.getWorkbench()
.getSharedImages();
//undo action
createDiagramUndoAction();
Action diagramUndoAction = this.diagramUndoAction;
diagramUndoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_UNDO));
bars.setGlobalActionHandler(ActionFactory.UNDO.getId(),
diagramUndoAction);
//redo action
createDiagramRedoAction();
Action diagramRedoAction = this.diagramRedoAction;
diagramRedoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_REDO));
bars.setGlobalActionHandler(ActionFactory.REDO.getId(),
diagramRedoAction);
}
The created Actions are overriding getDescription(), getText(),
isEnabled() and run(). Get the label and description like this:
editingDomain.getCommandStack().getUndoCommand().getDescript ion().
To resolve if it is enabled, do it like this:
editingDomain.getCommandStack().canUndo().
And of course running the action like this:
editingDomain.getCommandStack().undo().
I hope this helps you to get it to work. In case you have any problems
to implement it, let me know.
Arne
Javier Cardenete schrieb:
> Hello Arne,
>
> Your workaround makes sense to me but I haven't been able to implement
> it. I don't really know how to change the Undo / Redo behavior of an
> editor. I've been trying to modify the default Undo/Redo actions by a
> new ones, but it didn't work. Could you give me a hint for it?
>
> Actually, my first goal was (and still is) to get a global Undo/Redo
> actions for the whole editor (EMF & GMF). I followed the tutorial on how
> to integrate both, and I was working on the unifying of Undo/Redo
> actions when I noticed the problem of changes in the PropertySheet not
> going to Undo/Redo in diagram. I implemented the
> multipageActionbarContributor and the SubActionbars2. THere is were I
> was trying to unify the actions, but it's not working so far. So right
> now what I have is:
> - Changes in PropertySheet only appear in Undo/Redo of the EMF Editor
> (and not in Diagram) --> Solution: your workaround
> - Changes in Diagram only appear in Undo/Redo of the Diagram Editor (and
> not in the EMF Editor) --> Solution: I guess unifying actions.
> - I implemented some Actions for the diagram Editor that change values
> in the model, using AbstractTransactionalCommand. I had to add the
> UndoContext of the DiagramEditor for those changes to be visible on the
> Undo/Redo actions of the Diagram (but they still don't appear in the EMF
> Editor --i guess because of the same as with direct modifications)
>
> So if u could give me a hint on how to unify both editor's actions and a
> little deeper explanation on this workaround, it'd be really helpful.
>
> And apart from this, is this problem with the property sheet page a Bug?
> Or there is something wrong in the definition models?
>
> Thanks,
> Javier.
>
>
> Arne escribió:
>> Hello,
>>
>> i just got this to work by implementing some workaround. It may be not
>> the best way to do it, but it works. (And also a global undo / redo for
>> a integrated EMF Editor, what i have, works perfect).
>>
>> First i changed the Undo / Redo behavior of the diagram editor to do
>> just the undo / redo on the command stack of the transactional editing
>> domain. That will make undo / redo for setting attributes in the
>> properties view available. But then there is no more undo / redo for
>> changes in the diagram like moving nodes.
>>
>> To get that to work i attached a operation history listener to the
>> operation history of the diagram editor. This listener reacts on newly
>> added commands to the diagram command stack. Whenever it gets such a
>> event, it creates a EMF command and commits the command that was in
>> relationship with that event to the EMF command .
>>
>> The "redo" und "undo" methods in the emf command are then redirecting
>> the undo and redo to call the method of the command, that was resolved
>> by the event. The "execute" method in the EMF command must not be
>> implemented, since the original command will be executed on the diagram
>> command stack.
>>
>> In a nutshell:
>> - i only use undo / redo with the methods of the commandstack of the
>> transactional editingdomain (NOT the command stack of the diagram edit
>> domain)
>> - everything that is run in the command stack of the diagram edit domain
>> (what affects the operation history of the diagram editor) gets
>> "wrapped" into a emf command that will executed on the command stack of
>> the transactional editing domain
>>
>> Arne
>>
>> Javier Cardenete schrieb:
>>> Hello all,
>>>
>>> I've been working with GMF for some months now and I didn't realize of a
>>> problem until now. When I make any change on an element through the
>>> PropertySheetPage, afterwards the undo/redo actions don't notice such a
>>> change. It's happening with the Mindmap example and with some other
>>> simple examples I made on my own. Is it sth weird or is it normal
>>> behavior?
>>>
>>> Thanks
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220597 is a reply to message #220474] |
Thu, 05 March 2009 13:16 |
Javier
Messages: 57
Registered: July 2009 |
Member |
|
|
Thanks for your answer, Arne, it helped a lot.
I'm having problems at one point though.
Im trying to implement the Actions inside the ActionBarContributor
class, but I can't access the EditingDomain.
From the ActionBarContributor, via getPage().getActiveEditor() what I
get is the EMF Editor (which can't be resolved cause the GMF Editor
doesn't import the other one).
Reading a little bit, theoretically in the ActionBarContributor the
actions should be defined (the identificators), but the handlers (the
implemented actions) should be provided in the Editor. I went to the
XXXDiagramEditorr and that task is supposed to be performed in the
createActions() method, but it does nothing.
So it'd be helpful if you could tell me how do you get to the
EditingDomain, and also if you know where is the right place to
implement such actions (for example, where does the generated program
implement the Global actions that it brings by default?)
Thanks again,
Javier.
Arne escribió:
> Hi,
>
> i had the same situation as you with a ingetrated EMF editor. With this
> you will have also all changes from the Diagram Editor in the EMF
> Editor-Tab. I will give you code snippets how i did everything. You will
> need to have one TransactionalEditingDomain for both Editor-Tabs to get
> everything to work. I do not know if the non-existing undo / redo for
> the property view is a bug. Also, i do not have the newest GMF version
> since i have to work with Eclipse 3.3. But i hope this workaround also
> works for you.
>
> At first do the changes to redirect the GMF commands to the EMF Editing
> domain's command stack:
>
> In the Main Editor class (XXXDiagramEditor) override the
> configureDiagramEditDomain Method:
>
> ------> changes in XXXDiagramEditor.java:
>
> @Override
> protected void configureDiagramEditDomain() {
> super.configureDiagramEditDomain();
>
> if (getOperationHistory() != null
> && getEditingDomain() != null) {
> redirecter = new
> RedirectToEmfCommandCommandListener(getEditingDomain());
>
> getOperationHistory().addOperationHistoryListener(redirecter );
> }
> }
>
>
>
>
> The RedirectToEmfCommandCommandListener wraps all commands that are
> executed on the History into EMF commands and executes them on the EMF
> command stack.
>
>
> ------> new Class: RedirectToEmfCommandCommandListener
>
>
>
> public class RedirectToEmfCommandCommandListener implements
> IOperationHistoryListener {
>
> private TransactionalEditingDomain emfEdit;
>
> public RedirectToEmfCommandCommandListener(TransactionalEditingDoma in
> emfEdit) {
>
> this.emfEdit = emfEdit;
> }
>
> public void historyNotification(OperationHistoryEvent event) {
>
> if (emfEdit != null) {
>
> // when operation has been added, wrap it into a emf command
> if (event.getEventType() ==
> OperationHistoryEvent.OPERATION_ADDED) {
>
> GMFToEMFWrapper wrap = new GMFToEMFWrapper(emfEdit,
>
> event.getOperation());
>
> emfEdit.getCommandStack().execute(wrap);
>
> }
>
> }
>
> }
>
> /**
> * Wrapper to wrap a GMF command into a EMF command
> *
> */
> public class GMFToEMFWrapper extends AbstractOverrideableCommand {
>
> private IUndoableOperation operation;
>
> protected GMFToEMFWrapper(EditingDomain domain, IUndoableOperation
> command) {
> super(domain);
> this.operation = command;
> }
>
> @Override
> public void doExecute() {
> // no execution needed, execution has been done on diagram
> // command stack
>
> }
>
> @Override
> public void doRedo() {
> try {
> operation.redo(null, null);
> }
> catch (Throwable e) {
>
> }
> }
>
> @Override
> public void doUndo() {
> if (operation != null) {
> try {
> operation.undo(null, null);
> }
> catch (Throwable e) {
>
> }
> }
> }
>
> @Override
> public boolean doCanExecute() {
> //just return true. nothing will be done on execution but it has
>
> //to be done, to get it on the "EMF-Command Stack"
> return true;
> }
>
> @Override
> public boolean doCanUndo() {
> if (operation != null) {
> return operation.canUndo();
> }
> else {
> return false;
> }
> }
>
> @Override
> public String doGetLabel() {
> if (operation != null) {
> return operation.getLabel();
> }
> else {
> return "Diagram-Operation";
> }
>
> }
>
> }
>
> }
>
>
>
> Now how to implement your own Undo / Redo:
>
> In the same package as the class for the diagram editor, you have a
> XXXXDiagramActionBarContributor. In this class, override the
> init(IActionBars) method. (I have a slightliy different situation, but
> it should work this way or at least gives you a idea how to do it)
>
>
> ------> XXXXDiagramActionBarContributor.java
>
> private Action diagramUndoAction;
>
> private Action diagramRedoAction;
>
>
> @Override
> public void init(IActionBars bars) {
>
>
> super.init(bars);
> ISharedImages sharedImages = PlatformUI.getWorkbench()
>
> .getSharedImages();
>
> //undo action
> createDiagramUndoAction();
>
> Action diagramUndoAction = this.diagramUndoAction;
>
>
> diagramUndoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_UNDO));
>
> bars.setGlobalActionHandler(ActionFactory.UNDO.getId(),
>
> diagramUndoAction);
>
> //redo action
>
> createDiagramRedoAction();
> Action diagramRedoAction = this.diagramRedoAction;
>
> diagramRedoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_REDO));
>
> bars.setGlobalActionHandler(ActionFactory.REDO.getId(),
>
>
> diagramRedoAction);
> }
>
>
> The created Actions are overriding getDescription(), getText(),
> isEnabled() and run(). Get the label and description like this:
> editingDomain.getCommandStack().getUndoCommand().getDescript ion().
> To resolve if it is enabled, do it like this:
> editingDomain.getCommandStack().canUndo().
>
> And of course running the action like this:
> editingDomain.getCommandStack().undo().
>
>
> I hope this helps you to get it to work. In case you have any problems
> to implement it, let me know.
>
> Arne
>
>
>
>
>
>
>
> Javier Cardenete schrieb:
>> Hello Arne,
>>
>> Your workaround makes sense to me but I haven't been able to implement
>> it. I don't really know how to change the Undo / Redo behavior of an
>> editor. I've been trying to modify the default Undo/Redo actions by a
>> new ones, but it didn't work. Could you give me a hint for it?
>>
>> Actually, my first goal was (and still is) to get a global Undo/Redo
>> actions for the whole editor (EMF & GMF). I followed the tutorial on how
>> to integrate both, and I was working on the unifying of Undo/Redo
>> actions when I noticed the problem of changes in the PropertySheet not
>> going to Undo/Redo in diagram. I implemented the
>> multipageActionbarContributor and the SubActionbars2. THere is were I
>> was trying to unify the actions, but it's not working so far. So right
>> now what I have is:
>> - Changes in PropertySheet only appear in Undo/Redo of the EMF Editor
>> (and not in Diagram) --> Solution: your workaround
>> - Changes in Diagram only appear in Undo/Redo of the Diagram Editor (and
>> not in the EMF Editor) --> Solution: I guess unifying actions.
>> - I implemented some Actions for the diagram Editor that change values
>> in the model, using AbstractTransactionalCommand. I had to add the
>> UndoContext of the DiagramEditor for those changes to be visible on the
>> Undo/Redo actions of the Diagram (but they still don't appear in the EMF
>> Editor --i guess because of the same as with direct modifications)
>>
>> So if u could give me a hint on how to unify both editor's actions and a
>> little deeper explanation on this workaround, it'd be really helpful.
>>
>> And apart from this, is this problem with the property sheet page a Bug?
>> Or there is something wrong in the definition models?
>>
>> Thanks,
>> Javier.
>>
>>
>> Arne escribió:
>>> Hello,
>>>
>>> i just got this to work by implementing some workaround. It may be not
>>> the best way to do it, but it works. (And also a global undo / redo for
>>> a integrated EMF Editor, what i have, works perfect).
>>>
>>> First i changed the Undo / Redo behavior of the diagram editor to do
>>> just the undo / redo on the command stack of the transactional editing
>>> domain. That will make undo / redo for setting attributes in the
>>> properties view available. But then there is no more undo / redo for
>>> changes in the diagram like moving nodes.
>>>
>>> To get that to work i attached a operation history listener to the
>>> operation history of the diagram editor. This listener reacts on newly
>>> added commands to the diagram command stack. Whenever it gets such a
>>> event, it creates a EMF command and commits the command that was in
>>> relationship with that event to the EMF command .
>>>
>>> The "redo" und "undo" methods in the emf command are then redirecting
>>> the undo and redo to call the method of the command, that was resolved
>>> by the event. The "execute" method in the EMF command must not be
>>> implemented, since the original command will be executed on the diagram
>>> command stack.
>>>
>>> In a nutshell:
>>> - i only use undo / redo with the methods of the commandstack of the
>>> transactional editingdomain (NOT the command stack of the diagram edit
>>> domain)
>>> - everything that is run in the command stack of the diagram edit domain
>>> (what affects the operation history of the diagram editor) gets
>>> "wrapped" into a emf command that will executed on the command stack of
>>> the transactional editing domain
>>>
>>> Arne
>>>
>>> Javier Cardenete schrieb:
>>>> Hello all,
>>>>
>>>> I've been working with GMF for some months now and I didn't realize of a
>>>> problem until now. When I make any change on an element through the
>>>> PropertySheetPage, afterwards the undo/redo actions don't notice such a
>>>> change. It's happening with the Mindmap example and with some other
>>>> simple examples I made on my own. Is it sth weird or is it normal
>>>> behavior?
>>>>
>>>> Thanks
|
|
|
| Re: Changes via PropertySheet and undo/redo [message #220625 is a reply to message #220597] |
Thu, 05 March 2009 20:24 |
| Eclipse User |
|
|
|
Originally posted by: Erazerx.gmx.de
Well, i have implemented my own contributor for the integration with the
emf editor. In case you followed the tutorial "Integrating EMF and GMF
Generated Editors" you also have created a contributor and there is a
pretty easy way for you to do it.
You should have created a XXXMultipageActionBarContributor for switching
between different actions. Therefore, this contributor keeps track of
active pages.
There should be a method like the following, where you create a diagram
contributor when your page is a instance of your diagram editor. Just
override the init() method of the diagram contributor and create your
actions there.
/**
* @return the sub cool bar manager for the diagram editor.
*/
public SubActionBarsExt getDiagramSubActionBars() {
if (myDiagramSubActionBars == null) {
myDiagramSubActionBars = new
SubActionBarsExt(getPage(),
myActionBars2,
new TopicMapDiagramActionBarContributor(){
@Override
public void init(IActionBars bars) {
super.init(bars);
//create actions and get editing domain from active page
....
};, " org.example.emfgmf.topicmap.presentation.DiagramActionContri butor ");
}
return myDiagramSubActionBars;
}
Javier Cardenete schrieb:
> Thanks for your answer, Arne, it helped a lot.
>
> I'm having problems at one point though.
> Im trying to implement the Actions inside the ActionBarContributor
> class, but I can't access the EditingDomain.
> From the ActionBarContributor, via getPage().getActiveEditor() what I
> get is the EMF Editor (which can't be resolved cause the GMF Editor
> doesn't import the other one).
> Reading a little bit, theoretically in the ActionBarContributor the
> actions should be defined (the identificators), but the handlers (the
> implemented actions) should be provided in the Editor. I went to the
> XXXDiagramEditorr and that task is supposed to be performed in the
> createActions() method, but it does nothing.
>
> So it'd be helpful if you could tell me how do you get to the
> EditingDomain, and also if you know where is the right place to
> implement such actions (for example, where does the generated program
> implement the Global actions that it brings by default?)
>
> Thanks again,
>
> Javier.
>
>
>
> Arne escribió:
>> Hi,
>>
>> i had the same situation as you with a ingetrated EMF editor. With this
>> you will have also all changes from the Diagram Editor in the EMF
>> Editor-Tab. I will give you code snippets how i did everything. You will
>> need to have one TransactionalEditingDomain for both Editor-Tabs to get
>> everything to work. I do not know if the non-existing undo / redo for
>> the property view is a bug. Also, i do not have the newest GMF version
>> since i have to work with Eclipse 3.3. But i hope this workaround also
>> works for you.
>>
>> At first do the changes to redirect the GMF commands to the EMF Editing
>> domain's command stack:
>>
>> In the Main Editor class (XXXDiagramEditor) override the
>> configureDiagramEditDomain Method:
>>
>> ------> changes in XXXDiagramEditor.java:
>>
>> @Override
>> protected void configureDiagramEditDomain() {
>> super.configureDiagramEditDomain();
>>
>> if (getOperationHistory() != null
>> && getEditingDomain() != null) {
>> redirecter = new
>> RedirectToEmfCommandCommandListener(getEditingDomain());
>>
>> getOperationHistory().addOperationHistoryListener(redirecter );
>> }
>> }
>>
>>
>>
>>
>> The RedirectToEmfCommandCommandListener wraps all commands that are
>> executed on the History into EMF commands and executes them on the EMF
>> command stack.
>>
>>
>> ------> new Class: RedirectToEmfCommandCommandListener
>>
>>
>>
>> public class RedirectToEmfCommandCommandListener implements
>> IOperationHistoryListener {
>>
>> private TransactionalEditingDomain emfEdit;
>>
>> public RedirectToEmfCommandCommandListener(TransactionalEditingDoma in
>> emfEdit) {
>>
>> this.emfEdit = emfEdit;
>> }
>>
>> public void historyNotification(OperationHistoryEvent event) {
>>
>> if (emfEdit != null) {
>>
>> // when operation has been added, wrap it into a emf command
>> if (event.getEventType() ==
>> OperationHistoryEvent.OPERATION_ADDED) {
>>
>> GMFToEMFWrapper wrap = new GMFToEMFWrapper(emfEdit,
>>
>> event.getOperation());
>>
>> emfEdit.getCommandStack().execute(wrap);
>>
>> }
>>
>> }
>>
>> }
>>
>> /**
>> * Wrapper to wrap a GMF command into a EMF command
>> *
>> */
>> public class GMFToEMFWrapper extends AbstractOverrideableCommand {
>>
>> private IUndoableOperation operation;
>>
>> protected GMFToEMFWrapper(EditingDomain domain, IUndoableOperation
>> command) {
>> super(domain);
>> this.operation = command;
>> }
>>
>> @Override
>> public void doExecute() {
>> // no execution needed, execution has been done on
>> diagram
>> // command stack
>>
>> }
>>
>> @Override
>> public void doRedo() {
>> try {
>> operation.redo(null, null);
>> }
>> catch (Throwable e) {
>>
>> }
>> }
>>
>> @Override
>> public void doUndo() {
>> if (operation != null) {
>> try {
>> operation.undo(null, null);
>> }
>> catch (Throwable e) {
>>
>> }
>> }
>> }
>>
>> @Override
>> public boolean doCanExecute() {
>> //just return true. nothing will be done on execution but it has
>>
>> //to be done, to get it on the "EMF-Command Stack"
>> return true;
>> }
>>
>> @Override
>> public boolean doCanUndo() {
>> if (operation != null) {
>> return operation.canUndo();
>> }
>> else {
>> return false;
>> }
>> }
>>
>> @Override
>> public String doGetLabel() {
>> if (operation != null) {
>> return operation.getLabel();
>> }
>> else {
>> return "Diagram-Operation";
>> }
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>> Now how to implement your own Undo / Redo:
>>
>> In the same package as the class for the diagram editor, you have a
>> XXXXDiagramActionBarContributor. In this class, override the
>> init(IActionBars) method. (I have a slightliy different situation, but
>> it should work this way or at least gives you a idea how to do it)
>>
>>
>> ------> XXXXDiagramActionBarContributor.java
>>
>> private Action diagramUndoAction;
>>
>> private Action diagramRedoAction;
>>
>>
>> @Override
>> public void init(IActionBars bars) {
>>
>>
>> super.init(bars);
>> ISharedImages sharedImages = PlatformUI.getWorkbench()
>>
>> .getSharedImages();
>>
>> //undo action
>> createDiagramUndoAction();
>>
>> Action diagramUndoAction = this.diagramUndoAction;
>>
>>
>> diagramUndoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_UNDO));
>>
>>
>> bars.setGlobalActionHandler(ActionFactory.UNDO.getId(),
>>
>> diagramUndoAction);
>>
>> //redo action
>>
>> createDiagramRedoAction();
>> Action diagramRedoAction = this.diagramRedoAction;
>>
>> diagramRedoAction.setImageDescriptor(sharedImages.getImageDe scriptor(ISharedImages.IMG_TOOL_REDO));
>>
>>
>> bars.setGlobalActionHandler(ActionFactory.REDO.getId(),
>>
>>
>> diagramRedoAction);
>> }
>>
>>
>> The created Actions are overriding getDescription(), getText(),
>> isEnabled() and run(). Get the label and description like this:
>> editingDomain.getCommandStack().getUndoCommand().getDescript ion().
>> To resolve if it is enabled, do it like this:
>> editingDomain.getCommandStack().canUndo().
>>
>> And of course running the action like this:
>> editingDomain.getCommandStack().undo().
>>
>>
>> I hope this helps you to get it to work. In case you have any problems
>> to implement it, let me know.
>>
>> Arne
>>
>>
>>
>>
>>
>>
>>
>> Javier Cardenete schrieb:
>>> Hello Arne,
>>>
>>> Your workaround makes sense to me but I haven't been able to implement
>>> it. I don't really know how to change the Undo / Redo behavior of an
>>> editor. I've been trying to modify the default Undo/Redo actions by a
>>> new ones, but it didn't work. Could you give me a hint for it?
>>>
>>> Actually, my first goal was (and still is) to get a global Undo/Redo
>>> actions for the whole editor (EMF & GMF). I followed the tutorial on how
>>> to integrate both, and I was working on the unifying of Undo/Redo
>>> actions when I noticed the problem of changes in the PropertySheet not
>>> going to Undo/Redo in diagram. I implemented the
>>> multipageActionbarContributor and the SubActionbars2. THere is were I
>>> was trying to unify the actions, but it's not working so far. So right
>>> now what I have is:
>>> - Changes in PropertySheet only appear in Undo/Redo of the EMF Editor
>>> (and not in Diagram) --> Solution: your workaround
>>> - Changes in Diagram only appear in Undo/Redo of the Diagram Editor (and
>>> not in the EMF Editor) --> Solution: I guess unifying actions.
>>> - I implemented some Actions for the diagram Editor that change values
>>> in the model, using AbstractTransactionalCommand. I had to add the
>>> UndoContext of the DiagramEditor for those changes to be visible on the
>>> Undo/Redo actions of the Diagram (but they still don't appear in the EMF
>>> Editor --i guess because of the same as with direct modifications)
>>>
>>> So if u could give me a hint on how to unify both editor's actions and a
>>> little deeper explanation on this workaround, it'd be really helpful.
>>>
>>> And apart from this, is this problem with the property sheet page a Bug?
>>> Or there is something wrong in the definition models?
>>>
>>> Thanks,
>>> Javier.
>>>
>>>
>>> Arne escribió:
>>>> Hello,
>>>>
>>>> i just got this to work by implementing some workaround. It may be not
>>>> the best way to do it, but it works. (And also a global undo / redo for
>>>> a integrated EMF Editor, what i have, works perfect).
>>>>
>>>> First i changed the Undo / Redo behavior of the diagram editor to do
>>>> just the undo / redo on the command stack of the transactional editing
>>>> domain. That will make undo / redo for setting attributes in the
>>>> properties view available. But then there is no more undo / redo for
>>>> changes in the diagram like moving nodes.
>>>>
>>>> To get that to work i attached a operation history listener to the
>>>> operation history of the diagram editor. This listener reacts on newly
>>>> added commands to the diagram command stack. Whenever it gets such a
>>>> event, it creates a EMF command and commits the command that was in
>>>> relationship with that event to the EMF command .
>>>>
>>>> The "redo" und "undo" methods in the emf command are then redirecting
>>>> the undo and redo to call the method of the command, that was resolved
>>>> by the event. The "execute" method in the EMF command must not be
>>>> implemented, since the original command will be executed on the diagram
>>>> command stack.
>>>>
>>>> In a nutshell:
>>>> - i only use undo / redo with the methods of the commandstack of the
>>>> transactional editingdomain (NOT the command stack of the diagram edit
>>>> domain)
>>>> - everything that is run in the command stack of the diagram edit
>>>> domain
>>>> (what affects the operation history of the diagram editor) gets
>>>> "wrapped" into a emf command that will executed on the command stack of
>>>> the transactional editing domain
>>>>
>>>> Arne
>>>>
>>>> Javier Cardenete schrieb:
>>>>> Hello all,
>>>>>
>>>>> I've been working with GMF for some months now and I didn't realize
>>>>> of a
>>>>> problem until now. When I make any change on an element through the
>>>>> PropertySheetPage, afterwards the undo/redo actions don't notice
>>>>> such a
>>>>> change. It's happening with the Mindmap example and with some other
>>>>> simple examples I made on my own. Is it sth weird or is it normal
>>>>> behavior?
>>>>>
>>>>> Thanks
|
|
| | |
Goto Forum:
Current Time: Thu Apr 18 12:29:52 GMT 2024
Powered by FUDForum. Page generated in 0.02630 seconds |
] 
Search
Help
Register
Login
Home
