LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"VI is not executable" and lvlibp bug?

Solved!
Go to solution

VI not executable.png

 

I'm getting this, but only with the installed Application.  The VI runs fine in development.  The built EXE works from the directory it gets built in.  It just the installed application that gets goofed.

I have the full LV2010 development environment but can't find the root of the issue.

 

Steps to reproduce:

1. Build the packed library in Reference Test.lvproj

2. Open Reference Caller.lvproj

3. Run Reference Caller.vi in Development -- All is good

4. Build the Reference Caller EXE and run it -- All is good

5. Build the Reference Caller Installer.

6. Run the Reference Caller Installer and then Launch it from the Start Menu or Program Files -- Get the error window shown above.

 

Our other packed libraries seem to be working well, so I'm wondering if this issue is particular to VI references and classes.

0 Kudos
Message 1 of 5
(2,363 Views)

A little additional information:

 

We have isolated the issue to only occurring when the VI reference is part of the Class data and the Class is built into a packed library.

If a regular lvlib is used, there are no issues.  We're trying to keep our code modular and encapsulated so there is a preference to stay with packed libraries if we can.

 

Still wondering if this is a bug or whether we're misusing the packed library.  Any hints or suggestions would be appreciated.

0 Kudos
Message 2 of 5
(2,351 Views)

I work with the OP.

 

I've determined that a control reference as part of the class data instead of a VI reference will also result in the same issue. As a conjecture, I believe that passing any refnum to the class data of a class part of a packed library will cause these relative path issues to appear. Can anyone else reproduce this, and could this have been fixed in LabVIEW 2011?

0 Kudos
Message 3 of 5
(2,341 Views)
Solution
Accepted by topic author Taki1999

I was able to reproduce the issue in LabVIEW 2010. I then tried to reproduce the problem in LabVIEW 2010 SP1 and LabVIEW 2011 and could not. So it seems the issue was fixed in newer versions. Unfortunately, I could not find workaround.information specific to your setup.

George M
National Instruments
Message 4 of 5
(2,326 Views)

Thanks gmart,

 

That's actually pretty good news for us since we have been contemplating migrating to LV2011.

I'll do a trial upgrade.  If it works, then I'll definitely give you the kudo and solution.

0 Kudos
Message 5 of 5
(2,323 Views)