Lookup Object Hierarchy.vi issue with PPL

[thomas-allibe-se]

LVCompositionPPLBug_2.zip

Issue

From Lookup Object Hierarchy.vi

We have two classes in a PPL:

• A.lvclass
• B.lvclass

B inherits from A.

When used with B, from the PPL, the LabVIEW internal VI Get Mutation History.vi returns the parent name (A.lvclass) without the good name qualification (in the example, LVCompositionPPLBug.lvlib:A.lvclass instead of LVCompositionPPLBug.lvlibp:A.lvclass, the p is missing).

This results in a Get LV Class Default Value By Name.vi error 1373.

This is maybe a bug, but it's also a vi not really intended for use. I'll create a ticket issue on NI website.

Possible fix

In the variant palette, there is a Get LabVIEW Class Parent And Member VI Information.vi allowing to get the class parent default value. But the VI behave weirdly in the sense that casting B.lvclass to LabVIEW Object makes this vi see the class as an instance of LabVIEW Object instead of an instance of B.lvclass, resulting in a null parent class...
This idea exchange is related.
A fix would be to use a Variant control input instead of a LabVIEW Object for Decompose LabVIEW Object and internals. But don't use Get LabVIEW Information.vi from Variant palette since the returned class name is not qualified.

But now it's ugly and it as an additional copy of the class...

Also, I don't know if Get LabVIEW Class Parent And Member VI Information.vi available in 2017...

[thomas-allibe-se]

Also, if we have classes A and B in a separate lvlib name GetParentClass.lvlib that is a dependency of LVCompositionPPLBug.lvlibp PPL, the Get Mutation History.vi from the PPL will return GetPArentClass.lvlib:A.lvclass instead of LVCompositionPPLBug.lvlibp:GetPArentClass.lvlib:A.lvclass.

So we can't just add a p letter to the first lvlib occurrence.

And, as far as I know, there's no way of guessing if the class is from the same PPL as the child class...

[thomas-allibe-se]

I've found a cleaner version of the Variant solution based on this post:

It's working both in development and run time and with PPL too.

We don't need to convert variant to LV class anymore and we dont need Get Mutation History.vi. The Get LabVIEW Class Parent And Member VI Information.vi can't return an interface (since it as a dedicated interface list output), so we only need to check LabVIEW Object to stop the loop.

Performance wise, I have no idea how it performs, but we can easily add a LV class -> default data cache to the vi.

A big issue though is that calling Decompose LabVIEW object.vi with the class instance as a LabVIEW Object won't work since the Variant VIs will see it as a LabVIEW Object....

So I'm still working on a fix...