Bug 403837 - Undo/Redo in a MultiPageEditor environment
Summary: Undo/Redo in a MultiPageEditor environment
Status: CLOSED WONTFIX
Alias: None
Product: Graphiti
Classification: Modeling
Component: Core (show other bugs)
Version: 0.9.0   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
Depends on:
Blocks:
 
Reported: 2013-03-19 15:25 EDT by Vitor Enio CLA
Modified: 2014-05-23 09:56 EDT (History)
4 users (show)

See Also:


Attachments
Stacktrace with more details. (7.74 KB, text/plain)
2013-03-19 15:25 EDT, Vitor Enio CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vitor Enio CLA 2013-03-19 15:25:05 EDT
Created attachment 228677 [details]
Stacktrace with more details.

I'm trying to implement an Undo/Redo behavior in a MultiPageEditor environment. The scenario consists in an editor that represents a Process and an element that represents a Subprocess. The subprocess and his editor has its own property sheet. By doubleclicking the subprocess element another editor page is created and activated. At this point I can edit the properties of the subprocess at the property sheet.

So, when I edit anything at the property sheet of the subprocess editor, everything is Ok. Undo/Redo works fine at this point. 

The problem is when I came back to the subprocess "parent" editor , the Process editor: trying to do any change that stacks an Undo/Redo action will throw an NPE (stacktrace is attached).

Debugging GEF/Graphiti internals, I found out that, when creating a new editor page, the stack actions are created again, and the WorkbenchPart field of these actions are setted as the new subprocess editor. Closing the subprocess disposes the WorkbenchPart corresponding to this editor, disposing all command stack related to it. 

Just backing to the process editor, without trigger any "activate part" command, the actions re-created on subprocess are not updated in the command stack. 

So, whatever changes I do on the process editor (important: these changes must not trigger any "activate part"), e.g. changing the subprocess name by his direct editing feature, Graphiti/GEF will try to get the commandstack from the already disposed workbenchPart of my subprocess, throwing a NPE because the last action registered on the action listeners was registered referencing the already disposed subprocess WorkbenchPart.

I'm using graphiti 0.9.2 with Eclipse Indigo 3.7.2


http://www.eclipse.org/forums/index.php/t/458598/
Comment 1 Rob Cernich CLA 2013-03-19 15:53:26 EDT
I'm also interesting in this functionality.  I've been trying to integrate the WST SSE EMF2DOM framework into my Graphiti based editor.  I have been able to get a shared command stack between the source and diagram editors, but it was not very pretty.  At this point, it's still a rough POC and save doesn't work, but the source can be found here: https://github.com/rcernich/tools/tree/text_editing/eclipse/plugins/org.switchyard.tools.ui.editor

FYI, I'd like to eventually get this EMF2DOM thing working to the point where it can be contributed back to Eclipse.  The generic bits are already broken out.  That said, it will probably be a while before I get back to this.

Hope it helps.

Best,
Rob
Comment 2 Michael Wenz CLA 2014-05-23 09:56:30 EDT
Coming back to this after quite some time I'm not sure if the Graphiti framework should do something about this.

In the MultiPageEditor you will probably need to ensure that the current set of globally registered actions is updated as soon as the page changes (or the currently active one is removed). Graphiti itself does not have a hook to notice this situation.

Also, as of Graphiti 0.10.0 there is the option to create and register the global actions yourself by overriding createActions in GraphicalEditor. Maybe you could also hook the actions or a wrapper around to your multi page editor and later delegate to the right sub editor?

I'm marking this as won't fix because of the above reasons. If that does not help in your case, please simply re-open this bug.