Project

General

Profile

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.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
11/19/2014
Due date:
% Done:

100%

Estimated time:

Description

  • 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(UndoRedoImpl.java:158), argument x is null (editor is non-null)
java.lang.NullPointerException
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.setTextAndPos(UndoRedoImpl.java:158)
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.undo(UndoRedoImpl.java:222)
    at org.fortiss.tooling.kernel.ui.util.UndoRedoImpl.keyReleased(UndoRedoImpl.java:186)
    at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:174)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108)
    at org.eclipse.swt.widgets.Text.sendKeyEvent(Text.java:1726)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
    at org.eclipse.swt.widgets.Widget.wmKeyUp(Widget.java:1927)
    at org.eclipse.swt.widgets.Control.WM_KEYUP(Control.java:4979)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:4644)
    at org.eclipse.swt.widgets.Text.windowProc(Text.java:2597)
    at org.eclipse.swt.widgets.Display.windowProc(Display.java:4977)
    at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
    at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:140)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.fortiss.af3.rcp.application.AF3Application.start(AF3Application.java:48)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
undoing-programmatic-change.png (55.8 KB) undoing-programmatic-change.png Simon Barner, 11/19/2014 05:36 PM

History

#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