asynchronous call vi path

[aputman]

I am trying to implement a splash screen that calls my main VI asynchronously and displays messages while the VI loads.  It all works properly in development system but it's not the case as an EXE.  This is my first attempt at calling a VI like this so i am sure that i am missing something simple. 

See the attached image.  The static reference points to a location on my server but I want to run the VI that is "Always Included" in my EXE build, not the VI from the server.  The VI Path returned here is a combination of the server path and the build location which is obviously not correct. 

What's really strange to me is that the main.vi does actually run, even though the path is wrong.  The splash screen shows messages received from main but when it gets to the loading config settings, it fails because the vi path is c:\program files\tester\main.exe\z\labview\tester and it can't find my INI file.  How do i load this VI dynamically and still be able to pass my notification refnum into it for my splash screen and return the proper VI path?  I tried removing the path property node below and just adding a path constant with main.vi as the value.  But it seems to be getting the path from the strict type reference (which i understand is for type only). 

[JÞB]

And that is not what you want to do!  You seem to be running Main.vi from the server not the exe.

"For Type Only" means just that-  the filename property should not be queried.  use the application property app.kind to switch between a path to the server or use a relative path to This.VI. 

[aputman]

splash.vi and main.vi are both in the same directory.  So I shouldn't have to check for app.kind.  Just wiring main.vi into the open reference should work, I think.

This launches the VI but it still returns a funky path (c:\program files\tester\main.exe\z\labview\tester\main.vi)when I call Current VI's Path from main.vi

[JoeWork]

Can you show how you built the executable?  What do the setup windows look like?

[JÞB]

Just wiring main.vi into the open reference should work, I think.

---

Uhmmmm... which main.vi will it find????  I guess that depends on the search paths.  strip the path of This.vi

[aputman]

I made a very simple main.vi and used it in place of my full application and built the exe and it works properly.  The VI resides on the server right next to the full VI and is included in the exe just like the other.  Something is going on in my full VI.

[Oligarlicky]

Here's an article about where LabVIEW will put your VI in your EXE. Basically, it has to find the common path of all your VIs and it starts recreating the folder structure in the exe from there

http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/referencing_files_in_applications/

[nathand]

You don't want to use a static VI reference - that defeats part of the purpose of having a splash screen! A static VI reference causes the referenced VI to be loaded into memory, and usually when you use a splash screen, you're expecting that it will take a while to load that VI and you want something visible on the screen while you're waiting. Instead of using a strict VI reference, create a constant from that reference, which will give you a VI type without referring to any specific VI (a bit like if you create a reference to a control, then create a constant from that reference). Although, if you do use a static VI reference, you can avoid all this by wiring a string containing "main.vi" instead of a path (Open VI Reference will also accept a string input). The fact that you're using a static VI reference, instead of a type specifier, explains why the Path property is valid.

The "funky" path is actually to be expected. LabVIEW now maintains relative paths within an executable, which allows multiple VIs with the same name to exist within an application (a requirement for supporting LabVIEW classes). A side effect is that since your VI is on a separate drive, you're getting what looks like an absolute path embedded within the EXE. This is now the normal behavior. If you don't want that, check the build options box that says "Use 8.x file layout."

[aputman]

---

The "funky" path is actually to be expected. LabVIEW now maintains relative paths within an executable, which allows multiple VIs with the same name to exist within an application (a requirement for supporting LabVIEW classes). A side effect is that since your VI is on a separate drive, you're getting what looks like an absolute path embedded within the EXE. This is now the normal behavior. If you don't want that, check the build options box that says "Use 8.x file layout."

---

This doesn't make sense to me because, like i said before, i created a new main1.vi that has minimal code, saved it to the same directory on the server, called it asynchronously from my splash screen just the same, and it works like i expect.  This is all within the same project file.  The VI path doesn't include the absolute path of the location on the server.  I'm about at my wits end over this...and all for a splash screen. 

[nathand · Accepted solution]

I'd bet that your full, complicated application is calling some VI that lives on the C drive, so in order to avoid any potential ambiguity, it uses the full path in the compiled application (on the off chance that your build includes two VIs with the same name at the same path but on different drives). Your simple application probably calls subVIs that are only on the Z drive, so there's no possibility of such confusion and it uses a shorter common path as the starting point.