Although LavaBlast mainly produces .NET-based solutions, we’re currently working on usability enhancements to our favourite requirements engineering tool, jUCMNav. jUCMNav is Java-based open source project (an Eclipse plug-in) for graphical software requirements modelling built using the Graphical Editing Framework (GEF) and the Eclipse Modeling Framework (EMF). Personally, I love the development cycle (with automatic incremental compilation) in Java/Eclipse. Writing plug-ins for Eclipse is tons of fun and there is an active community contributing to the Eclipse project (and its subprojects). However, I often find myself wanting to do something simple and having to fiddle around with 12 source code excerpts to make it work as a whole for various reasons.
- You know how to do something for general Eclipse plug-ins but not where to hook it up to your GEF editor.
- You know how to do something in SWT/Draw2D but not where to hook it up to your GEF editor.
- You get burned by random conventions that aren’t clearly defined
- Some file you would think would be included is ignored by your build script.
In any case, I’ll post a few technical details on some of the issues we had to solve, hoping it will help someone out in the future!
Scenario: You are using a WizardDialog in your application, but the ? button does nothing.
Or: How do you set up contextual help on a WizardDialog in Eclipse?
Step 1) Create a help_contexts.xml file.
<?xml version="1.0" encoding="UTF-8"?>
<?NLS TYPE="org.eclipse.help.contexts"?>
<contexts>
<context id="help_general" >
<description>test</description>
<topic label="test" href="http://domain.com/help.html"/>
</context>
</contexts>
- The name of the XML file is not important.
- Important: DO NOT include your plug-in name in the context id (here: “help_general”)
- Important: DO NOT include any periods in the context id (here: “help_general”, not “help.general”)
- You may reference local help files – they don’t need to be external.
Step 2) Reference the contexts file from your plugin.xml
<extension point="org.eclipse.help.contexts">
<contexts file="help_contexts.xml">
</contexts>
</extension>
- The contexts element has an optional plugin-id parameter. Leave this empty unless you want to contribute help contexts to another plug-in.
Step 3) Ensure help_contexts.xml is packaged with your application
- Edit your build.properties file to ensure it includes help_contexts.xml (bin.includes = …, help_contexts.xml, …)
- Note the Bundle-SymbolicName in your Manifest.MF (also visible in your plugin.xml editor). If none found, note Bundle-Name. Example: com.domain.myplugin
Step 4) Set the context id in the WizardPage
public class MyWizardPage extends WizardPage
public void createControl(Composite parent) {
PlatformUI.getWorkbench.getHelpSystem.setHelp(parent, "com.domain.myplugin.help_general");
}
}
- You must add this in each WizardPage, not the WizardDialog.
143980ca-f494-4261-869d-756eff31ebd9|0|.0