Polymorphic API of Private Methods breaking build

[jgcode]

Ok, this one got me late last night:

I have a Polymorphic VI as a member of a LabVIEW Project Class Library that I want to form the API of the Class.

I don't want users to place specific instances of the methods in the Polymorphic VI on the BD, only to use the Polymorphic VI itself.

So I make the methods Private Scope and the Polymorphic VI Public scope... ...everything is all good running from source.

Build time comes around and I start getting build errors (see below of the description), it doesn't point to the Class Library directly, but as it turns out, the calling VIs of the Polymorphic VI.

An error occurred while saving the following file:C:\Users\developer2\Desktop\Private Polymorphic Class Members\[b]main.vi[/b]Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCallerPossible reason(s):LabVIEW:  Cannot save a bad VI without its block diagram.

So, after I was able to figure that out out I changed the calling method's scope from Private to Public and then everything was ok when building.

I then played some more today and found out that if I uncheck Remove unused polymorphic VI instances in the Build Spec, the error goes away.

I have attached some code if anyone wants to replicate it. Just toggle the VI.vi Scope from Private to Public or change the Build Spec as above.

Thoughts?

Is there a problem doing what I was doing? Or Is this a bug? If so, is it a known issue?

Cheers

-JG

Private Polymorphic Class Members LV2009.zip

[ShaunR]

Why are you using polymorphic VIs? They are data bound. Shouldn't you be using dynamic dispatch or some other dark magic to choose the instance at run-time?

Edited September 28, 2010 by ShaunR

[jgcode]

Why are you using polymorphic VIs? They are data bound. Shouldn't you be using dynamic dispatch or some other dark magic to choose the instance at run-time?

Yes, the reason I use the Polymorphic VI is to provide easy access for datatype conversion, just like other functions in LabVIEW or OpenG (it is just wrappers of the main code). In this case, I didn't have to use Class Library, but chose to, because I like it.

[shoneill]

Why are you using polymorphic VIs? They are data bound. Shouldn't you be using dynamic dispatch or some other dark magic to choose the instance at run-time?

Personally I find the use of polymorphic VIs (The ones with drop-down list, not auto-selecting ones) with LVOOP because it gives a one-stop shop for the API, not neccessarily the underlying objects.

Each element in the polamorohic VI can be a different accessor or method class which the user can use at will. The input class is obviously always dynamic dispatch, thus unifying the advantages of both. This is all pre-2010. I'm aware some of these functions are now supported in LV 2010 natively.

Shane

[jgcode]

Personally I find the use of polymorphic VIs (The ones with drop-down list, not auto-selecting ones) with LVOOP because it gives a one-stop shop for the API, not neccessarily the underlying objects.

Yes, I also do this. Although in the above implementation, it was for wrappers that support datatypes.

...The input class is obviously always dynamic dispatch, thus unifying the advantages of both. This is all pre-2010. ....

How do you get this to work?

AFAIK Polymorphic VI cannot have DD inputs?

[Francois Normandin]

How do you get this to work?

AFAIK Polymorphic VI cannot have DD inputs?

I guess he means to select the Constructor...

[shoneill]

How do you get this to work?

AFAIK Polymorphic VI cannot have DD inputs?

Correct, my bad.

Given that an API is essentially given, the class is set for the base class defining the API but it will accept child classes no problem. SO no DD, I had a speak malfunction.

Shane

[jgcode]

So I make the methods Private Scope and the Polymorphic VI Public scope... ...everything is all good running from source.

Build time comes around and I start getting build errors (see below of the description), it doesn't point to the Class Library directly, but as it turns out, the calling VIs of the Polymorphic VI.

Unfortunately this also breaks the build when using non-Class VIs

(LV 2010)

[gregstoll]

Hi JG -

You are correct - this is a result of the way we treat Polymorphic VIs in AppBuilder. After stripping the PolyVI, the caller is broken because it's trying to call a private VI. Our suggested workaround is (as you discovered) to turn off "Remove unused polymorphic VI instances" in the build specification.

This issue is tracked internally as CAR #212136.

Greg Stoll

LabVIEW R&D

National Instruments

[jgcode]

Thanks for the quick feedback Greg. I actually like the feature and looked forward to it being fixed for builds as I like to force the poly as the API (and only API) of my module\component.