Cannot build application that contains polymorphic VIs

[bcur]

I can complie a VI from a project into an executable, but when I double-click on the executable, the attached error messages pop up. Swapfile and ShiftSimpleHashTable are classes containing polymorphic VIs. Complling with debugging, without disconnecting or removing anything doesn't affect the error. The VI in question runs perfectly in the professional development environment.
 

Message Edited by bcur on 07-18-2008 12:04 PM

Message Edited by bcur on 07-18-2008 12:07 PM

[gmart]

I believe this is a known issue with LabVIEW 8.5 - http://zone.ni.com/devzone/cda/tut/p/id/6449#51862%2049GE2P00%20by%20Category

[bcur]

I tried the workaround on the link. There was no effect on the error.

Below is the relevant section from the link in the previous message.

Stand-alone application cannot load a class that includes polyVIs
A LabVIEW-built application that uses a LabVIEW class which contains a polymorphic VI does not function if the build options are set to include unused polymorphic VI instances, or if the polymorphic VI is in a plug-in to a built application that is outside the application.

Workaround—Choose to exclude unused polymorphic VI instances by selecting the Remove unused polymorphic VI instances option on the Additional Exclusions page.

Date Added—09/01/2007

[jpaul]

Hi bcur,

Would you be able to post your VI so that I can try to reproduce the error that you are seeing? I want to confirm that you are using LabVIEW 8.5.1 as well? Thanks!

Cheers,

Jonah
Applications Engineer
National Instruments

[bcur]

I am running labView 8.5 according to Help->About Labview, not 8.5.1. I would be happy to post my VI for you, but the program is has source code approximately 10MB. Should I just post the subVI that the program says it can't load, or is there some way you would like me to post the entire program?

[JeffBoettcher]

Thank you for the offer, but in the end there is no need for you to post your application.  I've reproduced the issue.  This was reported to R&D (# 107365) for further investigation.  For internal reference, # 51862 is also related.

[JeffBoettcher]

I apologize, I may have posted in haste...  I now notice that you say the workaround listed did not work for you.  Given this, it would still be useful for us to see your code, but I'm afraid it wouldn't be very useful to just post the one VI.  If you can ZIP everything up, I'm not sure what kind of size restrictions this message board imposes on file uploads, but hopefully it would allow the upload.

Another workaround, albeit not very pleasant, would be to not have the poly VIs be members of your LVClass.

[bcur]

I managed to get the program to complie and run correctly as an executable yesterday by replacing all of the self-created polymorphic subVIs with normal VIs that performed the same functions (minus the dynamic connectors). It turns out that the executable would complain upon opening if the classes used in any part of the VI hierachy contained polymorphic VIs. Even if the polymorphic VIs where not used, the executable would complain if the VIs where in the class.