Bug #2159

NPE in Properties View when undoing a change that has been performed programatically

Added by Simon Barner almost 6 years ago. Updated almost 3 years ago.

Start date:
Due date:
% Done:


Estimated time:


  • Open SimpleTrafficLightsExample
  • Open TL-Architecture->Merge->Root State
  • Select forwardBoth transition
  • Apply "Check NoVal" in Properties View
  • In the "Missing NoVal Check" dialog, select mergeInButtonA and mergeInButtonB
  • Observe that the guard condition has been extended
  • CTRL+Z (undo) leads to below stack trace, presumably because the change has not been issued by an editing action, but programatically
  • Hint: in at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.setTextAndPos(, argument x is null (editor is non-null)
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.setTextAndPos(
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.undo(
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.keyReleased(
    at org.eclipse.swt.widgets.TypedListener.handleEvent(
    at org.eclipse.swt.widgets.EventTable.sendEvent(
    at org.eclipse.swt.widgets.Widget.sendEvent(
    at org.eclipse.swt.widgets.Widget.sendEvent(
    at org.eclipse.swt.widgets.Widget.sendEvent(
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(
    at org.eclipse.swt.widgets.Text.sendKeyEvent(
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(
    at org.eclipse.swt.widgets.Widget.wmKeyUp(
    at org.eclipse.swt.widgets.Control.WM_KEYUP(
    at org.eclipse.swt.widgets.Control.windowProc(
    at org.eclipse.swt.widgets.Text.windowProc(
    at org.eclipse.swt.widgets.Display.windowProc(
    at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
    at org.eclipse.swt.internal.win32.OS.DispatchMessage(
    at org.eclipse.swt.widgets.Display.readAndDispatch(
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(
    at org.eclipse.ui.internal.Workbench$
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(
    at org.fortiss.af3.rcp.application.AF3Application.start(
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.eclipse.equinox.launcher.Main.invokeFramework(
    at org.eclipse.equinox.launcher.Main.basicRun(
    at org.eclipse.equinox.launcher.Main.main(
undoing-programmatic-change.png (55.8 KB) undoing-programmatic-change.png Simon Barner, 11/19/2014 05:36 PM


#1 Updated by Anonymous almost 6 years ago

  • Assignee set to Anonymous
  • Target version set to AF3 2.7 RC4 (bugs fixed)

#2 Updated by Anonymous almost 6 years ago

That's indeed the reason. This UndoRedoImpl is a quick hack to prevent the lack of undo/redo skills for some particular SWT widgets. I'll fix it so that no exception happens, but not sure if I can make the undo to work. Instead it would probably be a no-op...

#3 Updated by Anonymous almost 6 years ago

  • Status changed from New to Resolved
  • Assignee changed from Anonymous to Simon Barner
  • % Done changed from 0 to 100

So it's fixed. Note that there is one additional step in the above step: one has to click in the text field before pressing Ctrl-Z. This looks like a detail but it changes the undo/redo handler: inside the text field, the undo/redo is a character-level undo/redo, outside it's a transaction-level undo/redo.

The change mentioned in the issue description is a transaction-level one. So you should actually not click in the text field but anywhere else before Ctrl-Z to work (I think even not clicking anywhere will put you on the good focus).

#4 Updated by Simon Barner almost 6 years ago

  • Status changed from Resolved to Closed

Verified fix.

#5 Updated by Simon Barner almost 3 years ago

  • Assignee deleted (Simon Barner)

Also available in: Atom PDF