Community
Participate
Working Groups
The problem seems that the preference is stored, but not made sure to also save the current page classname. org.eclipse.core.runtime.AssertionFailedException: null argument: at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:88) at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:76) at org.eclipse.jface.preference.PreferenceNode.createObject(PreferenceNode.java:137) at org.eclipse.jface.preference.PreferenceNode.createPage(PreferenceNode.java:149) at org.eclipse.jface.preference.PreferenceDialog.createPage(PreferenceDialog.java:1280) at org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:1166) at org.eclipse.jface.preference.PreferenceDialog$5.lambda$0(PreferenceDialog.java:660) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74) at org.eclipse.jface.preference.PreferenceDialog$5.selectionChanged(PreferenceDialog.java:657) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:823) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:820) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1663) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1084) at org.eclipse.jface.preference.PreferenceDialog.selectSavedItem(PreferenceDialog.java:990) at org.eclipse.jface.preference.PreferenceDialog.lambda$0(PreferenceDialog.java:348) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74) at org.eclipse.jface.preference.PreferenceDialog.createContents(PreferenceDialog.java:345) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1094)
What are the steps to reproduce? Is this a regression in 4.20?
The problem itself is triggered by org.eclipse.jface.preference.PreferenceDialog.close() that disposes all resources of its manager. That means that afterwards the manager is in a state where it does not have a page and its classname is null if constructed from a page instance. one way would be that PreferenceNode.disposeResources() safes the classname of the page before disposing (but this won't work if the page has special constructor arguments). another option would be that do *not* dispose the page if it was not created (e.g. classname == null) from this preference node.
Created attachment 286417 [details] Snippet demonstrating the behaviour 1) Click on the button once -> a preference dialog shows up 2) Press cancel 3) Click on the button again -> AssertionFailedException: null argument
(In reply to Andrey Loskutov from comment #1) > Is this a regression in 4.20? I don't think so, it seems most people simply recreate the manager on every dialog open... or use the PreferenceNode.PreferenceNode(String, String, ImageDescriptor, String) constructor. PreferenceNode seems a bit inconsistent in its handling anyways, eg. getLabelText delegates to the page, but getLabelImage do not, if the page is not, createPage do not use the #setPage method, createObject is private so one can't override it ... Current workaround is to override createPage/getLabelText but that's a bit cumbersome...
