Make sure that quitting time is followed by happy hour.

As mentioned earlier, a compiled LabVIEW application behaves similarly to the development system when terminating.  Namely, it leaves the main window on the screen, waiting for you to close it.  That’s handy in the DevSys, because you usually want to work some more on the program after quitting.

But in an executable, it’s not so good, because the user doesn’t understand why the window hangs around.

The earlier article offered a way to have it both ways by simply detecting whether or not you were running with the main VI from an LLB, or something else, and performing a QUIT LABVIEW if it was something else.

With the advent of LabVIEW 2009, the scheme of detecting whether you were in an LLB or not was broken, because LV2009 started putting VIs into an EXE using the folder structure that they came from.  Before 2009, an EXE was a container for ALL VIs in the program, regardless of their folder structure on disk.  It was like having one folder.

Using THIS VI’s PATH would point to one of those VIs, stripping it ONCE would point to the container, and stripping it TWICE would refer to the containing folder.

With LV2009 and later, we can no longer use that logic.  What we do instead is to examine the path to MAIN:

• If we find an “.EXE”  in it, then we are in an executable, and we strip twice to get the containing folder
• else if we find “.LLB” in it, we are in a library, and we strip twice (from the point of the LLB) to get the containing folder
• else if we find “.VI” in it, we are in a stand-alone VI and strip ONCE to get to the containing folder

The attached VI is a replacement for the ROOT FOLDER vi mentioned in the earlier article, and is in LV 2009 format  (works in LV2010, too).

Use it when you’re ready to quit – see this snippet:

Click to download the Root Folder.vi .

By using the NOT IN LIBRARY signal as an input for QUIT LABVIEW, you can run the same code unmodified in an app, or in the DevSys, and it does the right thing either way.