Ignition 8 ExtensibleComponents without Extension Functions

3rd Party Modules
, ,
1

Hello IA,

When developing a Vision Component that implements the ExtensibleComponent interface on ignition 8 (8.0 and 8.1), at least 1 valid Extension Function must be provided, or else the customization Window will throw Console NPEs whenever the user clicks OK or APPLY. The main issue this introduces is brining Ignition 7 components into Ignition 8.

Now with that being said- Refactoring is far from impossible; developers can simply provide 1 Extension Function for all ExtensibleComponents, or remove the unused ExtensibleComponent inheritances. Unfortunately, this is easier said than done, and I wanted to ask about the possibility of continuing support for “Extension-Functionless ExtensibleComponents” for Vision in Ignition 8.

For example, if a developer creates a Vision component in Ignition 7, extends IA’s PMITable, and provides no extension functions, this is fine. Users can open up the scripting customization window on the component, without the NPE being thrown. If this same code is brought to Ignition 8, it is a problem, because the PMITable innately inherits ExtensibleComponent, and the lack of Extension Functions will cause the NPE to be thrown in the Scripting window.

Since PMITables are in the SDK, we cannot directly control its inheritance hierarchy. Refactoring our Vision component so that it stops extending the PMITable (turning the PMITable into a reference field) is certainly possible- it just appears to generate a lot of refactoring work. We anticipate the refactoring work to be a non-trivial use of time and resources, so I thought I’d at least try my luck at seeing if we could potentially acquire some support on IA’s side, before committing our resources for this job.

NPE.txt (3.1 KB)

2

Sounds like you are not copying your superclass' BeanInfo's list of extension functions. See this example:

3

And if you really don’t want the table’s extension functions to show through, I suspect that setting that property to an empty list will fix your NPE.

4

That you’re getting an NPE appears to be a bug we introduced during a big refactoring effort to support JDK 11 back in Feb 2019… we’ll get it fixed in an upcoming 8.1.x release.

5

What if you just return an empty map from getExtensionFunctions()?

6

Hello everyone, thank you for taking the time to look at this;

It’s good news for my side to hear that it is an (alleged) bug that has been spotted for a fix.

To answer PGriffith and pturmel’s suggestion: Unfortunately, returning empty or null Extension Function collections still seems to cause the NPE to propagate.

With all that being said, I do personally like the idea of Exposing/Inheriting the parent Extension Functions. However, as pturmel alluded to, this will expose functions we may have intentionally wanted to suppress.

7

If you look carefully at my linked example, you'll see that I am suppressing a superclass extension function.

8

I do like (in the snippet example) that I can pick-and-choose functions to inherit; I see that “getXTraceLabel” was filtered out, and allows the other Extension Function(s) from PMIChart to come through-

But in the case where I want my hypothetical PMIChart-extending component to feature 0 Functions, I may be out of luck because an empty list of Extension Functions does not avoid the NPE (as far as what I can tellf from tests- please correct me if I am mistaken about this).

I can think up a couple of different ways to refactor components to work for Ignition 8, but before I commit (what I think will be a significant amount of) time into doing so, I wanted to double-check to see if this would be declared a bug, or if this was purposeful enforcement of ExtensibleComponent’s intended use.

9

Have you tried it? In your BeanInfo? The designer runs off the BeanInfo, not the getExtensionFunctions() method of the actual component.

These two lines in initDesc():

List<ExtensionFunctionDescriptor> extensionFunctionList = new ArrayList<ExtensionFunctionDescriptor>();
bean.setValue("vision-extension-functions", extensionFunctionList);
10

Yes, I have tried returning the Extension Functions in the component class, the BeanInfo class, and both at the same time. I have also tried these combinations with both null and empty collections, but have not had success in avoiding the NPE.