Wrong "Current VI's Path" in LV 2009

[Norbert_B]

Klaus,

the primitive "Current VI's Path" always did, and presumably always will return the complete path to the vi. If the vi resides in an executable, the primitive always did (and always will be) return the path like <Exe-path>\<name of exe>.exe\<name of vi>.vi.

There has been no change in LV 2009 in this regard.

The thread Daniel linked to lists all changes in regard to executables build with LV 2009. Setting the checkmark in "Use LabVIEW 8.x File Layout" will force LV to build executables like LV 8.x and earlier did.

The change done in 2009 will therefore only take place if this setting is not selected and only for VIs in a subfolder in regard to the toplevel VI.

Is it possible that you were using a special subvi looking the same but truncating paths as needed?

hope this helps,

Norbert 

[Norbert_B]

---

Ben wrote:

[...]I have a a re-use VI that I have been using since LV 6.0 to resolve the differences in paths between the development and exe environments. [...]

Ben 

---

Let me guess:

There is something in it with "Call Chain" and other decent stuff, right? 🙂

Norbert 

[dan_u]

---

Norbert B wrote:

---

Ben wrote:

[...]I have a a re-use VI that I have been using since LV 6.0 to resolve the differences in paths between the development and exe environments. [...]

Ben 

---

Let me guess:

There is something in it with "Call Chain" and other decent stuff, right? 🙂

Norbert 

---

I would guess just an application.kind property node with an additional strip path in the "Run Time System" case 

[Ben]

---

Norbert B wrote:

---

Ben wrote:

[...]I have a a re-use VI that I have been using since LV 6.0 to resolve the differences in paths between the development and exe environments. [...]

Ben 

---

Let me guess:

There is something in it with "Call Chain" and other decent stuff, right? 🙂

Norbert 

---

Actually mine is a more flexible in that it does not depend starting with VI path. It works by repeatedly striping the path until a folder is found.

Yair posted some code that illustrates the idea in this thread.

My re-use code is very similar to the While loop but with different checks and error checking thrown in for good measure.

Ben

[Klaus_M]

Norbert, Daniel and all

Using the switch "Use LabVIEW 8.x File Layout" solves my problem.

Attached is the vi, that does not work without this switch.

This very old VI (worked from LV6.x til 8.2.1) also detects, if it is called out of an *.exe and activates the "Runtime" boolean.

Origin of the *.exe:

F:\Projekte\RFbeam_DT1\DT1_LabVIEW\Builds

Return without compatibility switch:

F:\Projekte\RFbeam_DT1\DT1_LabVIEW\Builds\DT1-Remote.exe\RFbeam_DT1\DT1_LabVIEW

It is obvious, that a "runtime detection" does not work with this interesting path output.

Return with compatibility switch:

F:\Projekte\RFbeam_DT1\DT1_LabVIEW\Builds

Thanks for all your answers!

Klaus

 

[Norbert_B · Accepted solution]

Klaus,

yes, "runtime detection" in thismanner is not recommended. LV 2009 keeps the folders of the modules in the executable, so this approach does not work anymore in LV 2009.

Either you move the VI in the rootfolder of your toplevel VI (so two folders up \RFbeam_DT1\DT1_LabVIEW )  or use the call chain approach as Ben uses. 

hope this helps,

Norbert 

PS: Keeping the setting for the file layout might be a temporary working solution, but i would not recommend you to stick on this. 

[tst]

I should point out that LV 2009 also has a new VI (I believe it's called "Application Directory" and is in the file constants palette) which returns the folder of the application, similar to what the image Ben posted shows. In the EXE it returns the EXE's folder and in the IDE it returns the project or top level VI folder. If you do want the folder, you should use that from now on.

[Klaus_M]

Norbert

I was too speedy. The call chain solution did not work in the real application without the compatibility switch, where the "call chain trick" is in sub VI.

It returns as a "Program Path" the same path as my original VI:

F:\Projekte\RFbeam_DT1\DT1_LabVIEW\Builds\DT1-Remote.exe\RFbeam_DT1\DT1_LabVIEW

instead of

F:\Projekte\RFbeam_DT1\DT1_LabVIEW\Builds

But why do it complicated, if it works as simple? 🙂

Attached is the VI code in for LabVIEW2009

I hope, this helps 

Klaus

[Klaus_M]

It would be a good practice to close the application reference 😉

Klaus

[Norbert_B]

Klaus,

the call chain approach works fine if the ultimate caller is located directly in the <name of exe>.exe. The call chain is just a list of VIs whicht are executed in the hierarchical order until finally "Call Chain" is called. Please note that the VIs names are in the list in inverted order, so the last entry should be the ultimate caller (or origin if you prefer this).

But as tst already wrote (and like you tested): it is best to use the Application Directory.vi from the File Constant palette.

Norbert