| Re: [ptp-dev] ETFw breakage |
> > There may have been some minor api adjustments, but there shouldn't
> > have been anything to require major code changes. Is the plugin
> > failing to build or are you seeing runtime errors / incorrect
> > behavior? A stack trace would be handy if you're seeing one.
> > Thanks,
> > Wyatt
>
> Not a build problem, it's a runtime one. Naturally it is in my
> hacks/fudges I added to make the custom GUI control work. Since what
> used to be the interface is no longer the same sematics, for
> example, I scan for a toolname match to insert my updated pane but
> that has now migrated to be a panename match, then when I do swap it
> over to panename I get more breakage as a NPE, so I'm debugging it
> now and will tell you more as I learn more. BTW, the NPE doesn't
> have any ETFw classes in it so I assume it's the GUI/SWT yelling
> about some field that is no longer being set. I'll keep checking and
> let you know...
OK, I found the problem. When you added paneName you removed
the assignment of toolName in ToolPane's setName() method.
For example, your ToolPane.java change history shows:
protected void setName(String name) {
- toolName = name;
+ paneName = name;
configID = name + ToolsOptionsConstants.TOOL_PANE_ID_SUFFIX;
configVarID = name + ToolsOptionsConstants.TOOL_PANE_VAR_ID_SUFFIX;
}
As a result toolName was never set to a value. Later I access the
ToolPane's toolName to set the tab's name and I get an NPE.
For example, here is my current code with its direct access to toolName:
TabItem tabItem = new TabItem(parentTabFolder, SWT.NULL);
tabItem.setText(panes[j].toolName);
So what should we do about this? Should we try to maintain upward
compatibility? For example, remove paneName and regress the code back
to use ToolName. I don't know what approach we should pursue. I need
your thoughts on this.