Calling Sub from Main

[MogaRaghu]

I am attaching a full folder that contaions a small project with three VI s. What I want to do is this : Run the MAIN.vi. Choose the required sub.vi to load and click Auto Load. The Main FP is closed and the Sub VI loads.

All working fine in design mode. But not working when EXE is built. ( No hardcoded path refernces are used )

Unable to find out why - for sure  there seems to be a problem with the file paths . And I am taking care to strip one more level when in RunTime mode. Still it does not work. Not sure why - any ideas welcome. 

Project done in LV 2012.

[GerdW]

Hi Raghunathan,

you really want us to debug your VIs when you password protect them? Really?

[MogaRaghu]

My Apologies.

The Sub VIs used were part of another project which was locked. I have now unlockes the sub VIs and rezipped the files.

I am really sorry about the slip up. ( just in case I have mossed any sub vi to unlock, the pwd is stars )

[RavensFan]

This is probably your problem.

Why Does My Executable Not Work When Using the Current VI's Path Constant?

[chembo · Accepted solution]

You don't need to strip the path one more time when the main VI runs as executable. Remove the executable check case structure in the CurPathToString.vi

In the CurPathToString.vi you get correctly the path to the caller, i.e. the top VI: MAIN.vi. It doesn't matter if the project runs in development environment or as executable, the MAIN.vi, SUBVI01.vi and SUBVI02.vi are in the exact same path, so you need to strip just one time the name of the top VI from the path.

[crossrulz · Accepted solution]

Chembo is correct.  You only need to use Strip Path once.  If you were trying to reference a file outside of the executable, things would be different and you should be using the Application Directory instead.  But since we are referring to VIs inside of your executable, there is no need to the extra Strip Path.  And you might want to think about using VI Path insde of going through the mess of getting a reference to the main and then getting its path.

[MogaRaghu]

Chembo,

That idea to drop the additional strip worked. Thanks.

Incidentally to get a clear idea on this process of path handling in design mode and run mode, when exactly will it be required to do the additional strip in run mode ? We anyway ( atleast me ) group all VIs of a project in the same directory and only group  things like Controls, Sub VIs into folders for easy refernce - but even these folders are inside of the same diirectory.

[chembo]

I usually keep only the main VI in the root directory of the project, along with a configuration file which includes any paths and filenames used in the project. This make is easy to move/add files without changing the code.

[Yamaeda]

---

@Raghunathan wrote:

Chembo,

That idea to drop the additional strip worked. Thanks.

Incidentally to get a clear idea on this process of path handling in design mode and run mode, when exactly will it be required to do the additional strip in run mode ? We anyway ( atleast me ) group all VIs of a project in the same directory and only group  things like Controls, Sub VIs into folders for easy refernce - but even these folders are inside of the same diirectory.

---

The additional strip is needed if you access files _outside_ of the .exe. For example a .ini in the install folder. 

If you check a VI path it includes the .exe as a "virtual folder", thus you'll need an extra strip.

/Y

[crossrulz]

---

Yamaeda wrote:

The additional strip is needed if you access files _outside_ of the .exe. For example a .ini in the install folder. 

If you check a VI path it includes the .exe as a "virtual folder", thus you'll need an extra strip.

---

But do be very careful with that.  Starting in LabVIEW 2009, the executables were a zip-like format, meaning that the folder heirarchy is maintained.  In LabVIEW 8.X, the executable was a flat format.  So the double strip was needed to get the folder of the executable.  In modern systems, you should be using the Application Directory primitive instead of the VI Path when looking for files outside of the executable (like ini files).  When in the development environment, the Application Directory gives the folder in which the project file is.  So that primitive is useful in both developement and run time environments.