Jump to content

Polymorphic API of Private Methods breaking build


Recommended Posts

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.

post-10325-050085300 1285652594_thumb.pn

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.

post-10325-076873600 1285652994_thumb.pn

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




			
		
Link to comment

Why are you using polymorphic VIs? blink.gif 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.

Link to comment

Why are you using polymorphic VIs? blink.gif 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

Link to comment

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?

Link to comment
  • 4 months later...

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)

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.