Open VI Reference Function and a RUN VI RUN VI Method Causes Error 1000 with version 2014

[robojeff]

Thanks JWCS

I read that yesterday and am able to launch the VI by itself.

Also, it does not appear to be open when stepping through the 

application.

[aputman]

In VI properties -> Execution, make sure that Run When Opened is unchecked. 

[robojeff]

---

@aputman wrote:

In VI properties -> Execution, make sure that Run When Opened is unchecked. 

---

Thanks Aputman

This are how the Execution VI Properties are set:

[robojeff]

---

@Norbert_B wrote:

Have you compiled that "plugin" VI with LV 2014?

---

I have just mass compiled everything in the folder (and sub-folders) where my code is with version 2014

then rebuilt the executable and then rebuild the installer.

I installed this one my test system and still receive the error 1000

[cblanchard]

Hi robojeff,

I notice in your first post that you are using LabVIEW 2014 with Windows 10.  This could be the source of the issue because Windows 10 is only compatible with LabVIEW 2015 SP1 or newer, as is shown on this compatibility document.  

Do you have access to LabVIEW 2015 SP1 or newer to try with your program?  If not, you can download an evaluation for LabVIEW 2016, or revert your OS to an older version.

-cblanchard

[Norbert_B]

---

@cblanchard wrote:

[...]  This could be the source of the issue because Windows 10 is only compatible with LabVIEW 2015 SP1 or newer, as is shown on this compatibility document.  [...]

---

This is not necessarily true. The compatibility chart only shows what is officially supported, hence what is being tested at NI.

Experience shows that older versions of LV have no issue running on Windows 10 at all. However, when an issue occurs, you have no support entitlement on that combination esp. if a newer version of LV solves that issue on that OS.

@But it is a good point @Op:

Can you double check if updating LV resolves the issue?

[robojeff]

---

@Norbert_B wrote:

---

@cblanchard wrote:

[...]  This could be the source of the issue because Windows 10 is only compatible with LabVIEW 2015 SP1 or newer, as is shown on this compatibility document.  [...]

---

This is not necessarily true. The compatibility chart only shows what is officially supported, hence what is being tested at NI.

Experience shows that older versions of LV have no issue running on Windows 10 at all. However, when an issue occurs, you have no support entitlement on that combination esp. if a newer version of LV solves that issue on that OS.

@But it is a good point @Op:

Can you double check if updating LV resolves the issue?

---

I loaded an evaluation copy of LabVIEW 2015 and when I run it I get the same error...

I have an old copy of the exe of this that was made some years ago by someone no longer with the company

but I don't know what version it was created by but it runs just fine

[Norbert_B]

Can you attach an excerpt of your application which shows the issue?

[aputman]

Actually, the problem is most likely that it can't find the VI.  I believe Labview 8.6 is one of the versions that lumps all of the VI's into a single directory under the EXE so that you only have to call the VI by name.  In newer versions, however, the EXE directory structure mimics the project directory unless you have the build flag "Use LabVIEW 8.x file layout" set to TRUE.  You'll need to specify a path relative to the application directory or the calling VI path.  

[rolfk]

It's not quite as you describe it. There is the LabVIEW 8.x file layout (same is basically used in LabVIEW before 8.x), which is basically all the code packed into an LLB and then put inside the EXE. This results in a single (virtual) folder with the EXE name and all the VIs inside this single folder. However this creates problems with name spaced VIs inside VI libraries and classes as there the VI's in different classes or libraries can have the same name, resulting in naming conflicts when put in a single folder. So they introduced in 8.6 or so a new format where the entire hierarchy is more or less packed into a ZIP file and then put inside the EXE. This allows to have class method VIs and library VIs with the same name to be stored inside the EXE instead of alongside it.

However this changes the path to the VI inside the executable, which your code needs to account for. And yes there seems to be a workaround for the old layout that Open VI Reference attempts to load a VI from inside an executable when only given a path. But if you wire in the IDE only a string to the Open VI Reference instead of a path, the VI must be definitely already in memory for the Open V Reference to succeed!

The quick workaround might be to enable the "Use LabVIEW 8.x file layout" option in the Advanced Settings for your application build. But I'm not sure that the Open VI Reference after 8.6 will actually attempt to load a VI not already in memory, when called with a string input only.