Community
Participate
Working Groups
Seems like all GMF based editors share the same undo stack. Say you have two "logic example" editors open A and B. If you do something in A, then you move to B, and try to undo, you undo what happened in A. Kinda strange. Another scenerio. Do something in A, go to B. Close A editor, delete file for A. Invoke undo in B, and you get the following exception. ENTRY org.eclipse.gmf.runtime.emf.commands.core 4 1 2005-09-30 10:26:59.494 !MESSAGE interval not found !STACK 0 org.eclipse.gmf.runtime.emf.core.internal.exceptions.MSLActionProtocolException: interval not found at java.lang.Throwable.<init>(Throwable.java) at java.lang.Throwable.<init>(Throwable.java) at org.eclipse.gmf.runtime.emf.core.exceptions.MSLRuntimeException.<init>(MSLRuntimeException.java:36) at org.eclipse.gmf.runtime.emf.core.internal.commands.MSLUndoStack.undoThroughInterval(MSLUndoStack.java:270) at org.eclipse.gmf.runtime.emf.core.internal.commands.MSLUndoStack$MSLUndoInterval.undo(MSLUndoStack.java:1430) at org.eclipse.gmf.runtime.emf.commands.core.command.CompositeModelCommand.undo(CompositeModelCommand.java:395) at org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCommand.doUndo(SemanticCreateCommand.java:95) at org.eclipse.gmf.runtime.common.core.command.AbstractCommand.undo(AbstractCommand.java:221) at org.eclipse.gmf.runtime.common.core.command.CompositeCommand.undo(CompositeCommand.java:476) at org.eclipse.gmf.runtime.common.core.command.CompositeCommand.undo(CompositeCommand.java:476) at org.eclipse.gmf.runtime.common.core.command.CommandManager.undo(CommandManager.java:888) at org.eclipse.gmf.runtime.common.ui.action.internal.actions.global.GlobalUndoAction.doRun(GlobalUndoAction.java:119) at org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandler.run(AbstractActionHandler.java:285) at org.eclipse.gmf.runtime.common.ui.action.ActionManager$2.run(ActionManager.java:298) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.gmf.runtime.common.ui.action.ActionManager.run(ActionManager.java:296) at org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandler.runWithEvent(AbstractActionHandler.java:303) at org.eclipse.ui.actions.RetargetAction.runWithEvent(RetargetAction.java:222) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)
At the moment, all Logic example diagrams share the same MEditingDomain and CommandManager. This causes the first symptom where we can undo changes made in one editor from another. The exception occurs because there is no coordination in GMF between the MEditingDomain and the CommandManager. When diagram A is deleted, the command stack in the editing domain is flushed, but the CommandManager (which feeds the 'Undo' action in the UI) is not notified. The CommandManager stack should be flushed when the editing domain stack is flushed. When GMF adopts the Eclipse Operations Framework, each diagram editor will have its own undo context, so the undo behaviour for each diagram editor will be independent of other diagram editors. The IOperationHistory associated with the MEditingDomain will be the one used to feed the 'Undo' action in the UI, so coordination between the two will not be required.
Moving to M3
Blocked on Bug 112826
As of the fix for Bug 112826, when you close the editor for A the undo stack is flushed for editor B because both editors are sharing the same editing domain. The exception no longer occurs when you delete the file for A. Making each diagram editor use its own editing domain, and hence have its own distinct undo stack depends on Bug 113850. Once the GMF diagram code has been migrated to the transaction API, each logic example diagram can use its own editing domain.
Fixed. Each GMF editor has its own editing domain, and allows the user to undo and redo the changes that are made in that editing domain. Now when you two logic example diagrams are open, the undo history for each is distinct from the other.
[target cleanup] 1.0 M6 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime Common was the original product and component for this bug
