Branden_Moore wrote:So I take it then that Designer does not bother digging into source beyond the initial CompilationUnit?
I'm not sure what you mean here. If you are refering to parsing, Designer generally only parses the current class your are editing (it will also parse NLS helper classes). Information about superclasses, custom widget, etc. is derived from bean info and reflection. Designer also has built-in knowledge about various Eclipse framework classes (like JFace Dialogs, ViewParts, EditorParts, ActionBarAdvisors, Perspectives, etc.) to allow it to create and display subclasses.
Branden_Moore wrote:The 'createButton()' method in org.eclipse.jface.Dialog does nothing fancy.
From a GUI builders POV, it is quite "fancy" as it is a specialized factory method only used in the context of JFace dialogs. It does not follow the normal pattern for SWT widget creation, so Designer builds in special knowledge about how to use it in the context of creating buttons for the Dialog's button bar.
You are the first person in three years who has asked for support for Dialog Buttons outside of the context of the dialog button bar. As I said earlier, we are looking into adding support for this.
Branden_Moore wrote:I suppose this would explain also why you override createButtonsForButtonBar() with a method that is exactly the same as that which it is overriding.
We create a createButtonsForButtonBar() in order to make it easy to add new dialog buttons into the list and to make it easy to override the default values in the superclass. If you don't intend to modify the button bar, you can remove that method and Designer won't care.
Branden_Moore wrote:As for the code associated with the Designer NPE, I do not have the authority to hand that code out, sorry.
If not that code, a reasonable approximation that exhibits the same problem would be fine as well. If we can reproduce the problem, we can probably do something about it.