The VI is not executable

[cirrusio]

Hello all,

I have a large user interface application (it communicates with an RT DAQ system) that is running in the development environment but the executable I have built throws an error (on the development machine) and has a broken error.  The message that I receive is "This VI is not executable.  The full development version of LabVIEW is required to fix the errors."  This error only occurs if I try to access a property of one particular class that I have developed.  The application has no errors in the development environment and there is nothing broken in this class or its children.  I know this may seem vague, but LV is not giving me any further hints as to what is happening.  I am currently running LV 12.0f1.

Thanks, Matt

[elset191]

Are you using LabVIEW Base?  I'm not sure if it would let you do things in the dev environment and not run-time though, if that was the case

[CMal]

Matt,

This sounds similar to a known issue in LabVIEW where building an application that uses polymorphic VIs causes the error you are seeing.  The workaround is to go into the application builder configuration, and uncheck "Remove unused polymorphic VI instance" in the "Additional Exclusions" page.

Chris M

[cirrusio]

Sigh...I had such great hopes for this, but alas it did not fix the problem, Chris.  That being said, this solution may be on to something.  I can build an executable that works if I am using a single, well defined class (and by this I mean that there is no ambiguity as in the current class implementation is known at runtime).  The difference between that exe and the current one of interest is that the implementation is defined at run time.  (see below)

Tim - I am using the professional version.

Matt

[cirrusio]

Compile. Compile. Re-compile.  Run. Fail...

OK...I think that I am starting to see the pattern here.  It seems that the failure (for whatever reason) is associated with a set of related classes (children and aggregates) and the exe breaks when I make pure accessor writes on the class (i.e. there is a 1-to-1 correlation between the input of the accessor and a property of the class).  It's still not clear to me why this is, but I think I might be able to work around this.  The unfortunate aspect is that this seems to be tied solely to the particular VI doing the calling; I can not seem to reproduce this behavior except in this particular UI.  I will verify this behavior tomorrow.

Cheers, Matt

[cirrusio]

Encountered this problem again with another accessor.  What's the deal?

My solution was to simply create a new accessor that provided the same functionality.