Community
Participate
Working Groups
If an Import/Export wizard (and potentially other wizards as well) are hidden via an Activity&ActivityPatternBinding and the wizard is a part of Category, then when the Category is opened in the Import/Export dialog window, it will briefly open and then close, requiring a second click of the category to open it. Steps to reproduce: 1. Select an existing or create a new Import/Export wizard from the plugin.xml and add it to a category 2. In the org.eclipse.ui.activities extension of plugin.xml, add an activity and create an activity pattern binding for that activity using the ID of the wizard (this should cause the wizard to be hidden). 3. Run the application and navigate to the location of the wizard/category. 4. Click on the category to open it. Notice that it temporarily opens and then closes.
AbstractExtensionWizardRegistry wizardRegistry = (AbstractExtensionWizardRegistry)PlatformUI.getWorkbench().getImportWizardRegistry(); IWizardCategory[] categories = PlatformUI.getWorkbench().getImportWizardRegistry().getRootCategory().getCategories(); for(IWizardDescriptor wizard : getAllWizards(categories)){ if(wizard.getCategory().getId().matches("test.example.restrictedWizard")){ WorkbenchWizardElement wizardElement = (WorkbenchWizardElement) wizard; wizardRegistry.removeExtension(wizardElement.getConfigurationElement().getDeclaringExtension(), new Object[]{wizardElement}); } } Programmatically, this solves the problem. Rather than dealing with the ActivityPatternBinding approach, we were able to de-register all particular wizards we did not want particular users to interact with. Debugging through, it seems like the ImportExportPage always maintains the original Wizard Element contents registered within the application. All the way down to the Control, the wizards we wanted to be hidden were still present within the TreeNode. However, at some point beyond the Wizard/Page handling process, it seems like an html blanket is laid over the top of the Dialog, resetting the expanded/selected/present state of all wizard elements within the ImportExport Tree. When interacting with any altered Node, an update is fired and resets the Page back to its initial state; However, if first a non-altered Node is interacted with, followed by an altered Node, the Page does not reset. Further investigation is still required to solve the ORIGINAL issue, but the above work-around does seem to solve our issue.
