Ignition Designer Preview Mode Fails: PMIComboBox NPE Fix

Stack Trace Anatomy and the Failing Call Path

The symptom: in the Ignition Designer, toggling from design mode to preview mode throws an exception on the Swing event thread. The Designer does not complete the mode change. The top of the trace is the part that matters:

Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
  at ...PMIComboBox.getTranslatedData(PMIComboBox.java:261)
  at ...PMIComboBox.localeChanged(PMIComboBox.java:377)
  at ...ComponentVisitor$LocaleChangedVisitor.visit(ComponentVisitor.java:332)
  at ...ComponentVisitor.walk(ComponentVisitor.java:77)
  at ...FPMIWindow$1.localeChanged(FPMIWindow.java:136)
  at ...DesignerLocalizationManager.fireLocaleChanged(DesignerLocalizationManager.java:517)
  at ...DesignerLocalizationManager.setCurrentLocale(DesignerLocalizationManager.java:143)
  at ...DesignerLocalizationManager.resetLocale(DesignerLocalizationManager.java:159)
  at ...FPMISystem.setMode(FPMISystem.java:38)
  at ...AbstractDesignableWorkspace.setDesignTime(AbstractDesignableWorkspace.java:304)

Read it bottom-up. The term mode switch here means the call to AbstractDesignableWorkspace.setDesignTime, which the Designer runs when preview is toggled. That call reaches FPMISystem.setMode, which calls DesignerLocalizationManager.resetLocale. Resetting the locale fires a locale-changed event to every open window. FPMIWindow then walks its component tree with ComponentVisitor$LocaleChangedVisitor. Each component gets a chance to re-translate its displayed text. When the visitor reaches a Dropdown List, the class behind it, PMIComboBox, calls getTranslatedData to rebuild its translated item list from the data property. If data is None (Java null), line 261 dereferences it and the NPE propagates. The exception escapes the mode-switch handler, so the Designer ends up half-transitioned.

This explains why the fault appears on the preview toggle and not while editing. In design mode, nothing forces the combo box to re-translate its data. Toggling preview always fires the locale reset, and the reset always visits every Dropdown List on the open window.

The lower frames (processKeyBinding, BasicMenuItemUI$Actions.actionPerformed, JMenuMerge) only show that the toggle came from the menu keyboard accelerator. They have no bearing on the cause.

Check 1: open the Designer output console and toggle preview. Expect the top frame to be PMIComboBox.getTranslatedData called from PMIComboBox.localeChanged. If the top frame names a different component class, this article does not describe your fault.

Affected Versions and Fix Status

This fault was observed in Designer 7.7.4. It was triggered by a project originally built in 7.5.13 and restored into a 7.7.4 test environment. The defect is fixed in 7.7.5-rc1: from that build on, PMIComboBox tolerates a null data property during the locale-change walk.

For builds between 7.7.4 and 7.7.5-rc1 not listed here, read the Designer version from Help → About. Then test with the reproduction procedure below rather than inferring from the version number.

Check 2: record the exact Designer version from Help → About. Expect 7.7.4 (or an earlier 7.7.x) if the trace in Check 1 matches. On 7.7.5-rc1 or later the trace should not recur from this cause.

Recovering a Designer Stuck in Preview Mode

When the NPE escapes the mode switch, the preview toggle can leave the workspace wedged. The Designer shows preview, but toggling back does not return to design mode. Do not force-quit the Designer; unsaved work in other windows is lost that way.

1. Close the window that threw the exception (close its tab in the workspace).
2. Toggle preview mode off. With no window holding the faulted Dropdown open, the mode switch completes.
3. Reopen the window in design mode.

Restarting the Designer also clears the stuck state, because the window reloads from its saved state. It is not a fix. If the window was saved with an empty or null Dropdown dataset, the next preview toggle fails the same way.

Check 3: after closing the window, toggle preview off. Expect the workspace to return to design mode and component selection handles to reappear on the reopened window.

Reproducing the Fault on a Scratch Window

Reproduce the defect in isolation before touching production windows. This confirms that the running build has the defect and gives you a baseline for testing the fix.

1. Create a new window.
2. Add a Button and a Dropdown List.
3. In the Button's actionPerformed event, set the Dropdown List's data property to None.
4. Make the output console visible.
5. Start preview mode.
6. Click the button.

The console shows the NPE and the Designer is stuck in preview mode. Recover it with the procedure in the previous section.

The button step is needed because the Dropdown only goes null at runtime, inside preview. Clicking it creates a null data property, and the next locale-change walk (including the one fired when leaving preview) hits it. A window saved with a Dropdown bound to an empty or null dataset reaches the same state without the button. The null is already present at the moment preview starts.

Check 4: on the scratch window, expect the NPE in the console after the button click and a stuck preview on 7.7.4. If no exception appears, the build already carries the fix. Proceed to the design-rule changes anyway.

Locating Dropdown Lists With Null Data

Every Dropdown List on the window being previewed is a candidate. The failing pattern in the migrated project was two Dropdown Lists whose data properties were bound to dataset-type custom properties on the root container. Both datasets were empty when the window was last saved, and an initialization script set them to None. Custom properties that hold query strings consumed by a component are a related case. If the query or its binding produces no dataset, the Dropdown's data can resolve to null.

For each window that fails, use the property editor to inspect each Dropdown List's data binding. Trace every binding back to its source property. Then search the window's event scripts for any assignment of None to that source.

Check 5: for each Dropdown on the failing window, list its data source and every script that writes to it. Expect at least one path that yields None or an empty dataset with no columns. That path is the one to change.

Replacing None With a Structured Placeholder Dataset

Assigning None to clear a dataset property is wrong practice, whatever the Designer version. The Dropdown List expects a dataset. By Ignition convention, a one-column dataset supplies both the value and the label, and a two-column dataset supplies the value and then the label. A null leaves the component with nothing to translate, render, or select against.

The verified workaround gives each dataset a column and a single blank row, and changes the initialization script to build that dataset instead of writing None:

# Wrong: leaves the Dropdown data null and triggers the NPE on preview toggle
#event.source.parent.distinctTagList = None
#event.source.parent.inclusiveDistinctTagList = None

# Correct: always assign a dataset with a defined column
event.source.parent.distinctTagList = system.dataset.toDataSet(["tags"], [[""]])
event.source.parent.inclusiveDistinctTagList = system.dataset.toDataSet(["tags"], [[""]])

Apply the same pattern to your own property names:

1. Replace every = None assignment to a dataset property that feeds a Dropdown with a system.dataset.toDataSet call that defines at least one column.
2. Open the root container custom property editor and set each saved dataset value to a dataset with the same column structure. That way the window is saved in a non-null state.
3. Save the window, close it, and reopen it so the saved state is what gets tested.

The single blank row appears as an empty selectable item in the list. If that entry is unwanted, test a column-defined dataset with zero rows on your build and use it only if the preview toggle stays clean. The blank-row form is the one proven against this defect. Keep the column name identical to the one the populated dataset uses. Downstream scripts and bindings that reference the column by name then keep working when the list is empty.

Check 6: in design mode, select each Dropdown and view its data property. Expect a dataset with at least one column (for the pattern above, column tags, one row), never a null or empty value.

Upgrading Past the Defect

The permanent fix is 7.7.5-rc1 or later. After upgrading, keep the placeholder-dataset scripts. A Dropdown whose data never goes null has no dependence on the fix, and any code outside the Designer's locale walk that reads the data behaves predictably.

1. Upgrade the Gateway to 7.7.5-rc1 or a later release, following your normal change-control and backup procedure.
2. Relaunch the Designer from the upgraded Gateway so the matching Designer build is loaded.
3. Rerun the scratch-window reproduction from the earlier section.

Check 7: on the upgraded Designer, run the reproduction. Expect the button to null the Dropdown without an NPE in the console, and expect the preview toggle to switch cleanly back to design mode.

End-to-End Verification

Run these checks on each window that previously failed, with the output console visible throughout.

1. Check A: open the window in design mode and toggle preview on. Expect no exception in the console and live component behavior in preview.
2. Check B: in preview, trigger every script that previously cleared a Dropdown dataset. Expect each Dropdown to show its placeholder entry or empty list, and expect no NPE.
3. Check C: trigger the scripts or bindings that populate the Dropdowns. Expect the real items to appear under the same column name.
4. Check D: toggle preview off. Expect the workspace to return to design mode without closing the window first.
5. Check E: save, close, and reopen the window, then repeat Checks A and D. Expect the same clean result, which proves the saved state holds a non-null dataset.
6. Check F: open every other window that contains a Dropdown List, especially windows migrated from 7.5.13, and toggle preview on and off once each. Expect no PMIComboBox.getTranslatedData frames anywhere in the console.

FAQ