How to get to top level VI/folder

[nealpederson]

Does anyone know how to calculate the path to the folder that a top level VI
or executable is in from a sub-VI that could be located anywhere?

"Current VI's Path" with some checking to see if it includes and executable
works fine if the sub-VI that uses it is in the same folder as the top level
VI or executable. Now I'd like to locate my sub-VI in a utility folder but
it no longer points me to the top level folder that I am interested in.
I'll attach my sub-VI for reference.



[Attachment VI or Application Directory.vi, see below]

[Wiebe@CARYA]

Hi,

Have a look at the Call Chain function (in Application Control). This gets
you the name of the top level vi (in the last element of the array). Open a
reference to this VI, get its path, strip the name, and see if it's in a
library. Sometimes you'll need the path including a library (when opening a
vi) and sometimes you don't (when opening a support file, like an ini file).

Regards,

Wiebe.


"Neal" wrote in message news:405637ce@newsgroups....
> Does anyone know how to calculate the path to the folder that a top level
VI
> or executable is in from a sub-VI that could be located anywhere?
>
> "Current VI's Path" with some checking to see if it includes and
executable
> works fine if the sub-VI that uses it is in the same folder as the t
op
level
> VI or executable. Now I'd like to locate my sub-VI in a utility folder
but
> it no longer points me to the top level folder that I am interested in.
> I'll attach my sub-VI for reference.
>
>
>

[nealpederson]

That worked like a charm, thanks! I was already stripping an extra path if
the VI was located inside an executable but I changed it to strip if inside
an llb like you suggested. I attached the updated VI with my copyright
removed so anyone can use it. It is really hand for building relative paths
to things like INI files and data folders! It also lets you know if the VI
is running inside and application (executable). This is handy because
shutting down is often handled differently when you are running in an
application versus the LabVIEW development environment.

"Wiebe@CARYA" wrote in message
news:4056ce06@newsgroups....
> Hi,
>
> Have a look at the Call Chain function (in Application Control). This gets
> you
the name of the top level vi (in the last element of the array). Open
a
> reference to this VI, get its path, strip the name, and see if it's in a
> library. Sometimes you'll need the path including a library (when opening
a
> vi) and sometimes you don't (when opening a support file, like an ini
file).
>
> Regards,
>
> Wiebe.
>
>
> "Neal" wrote in message news:405637ce@newsgroups....
> > Does anyone know how to calculate the path to the folder that a top
level
> VI
> > or executable is in from a sub-VI that could be located anywhere?
> >
> > "Current VI's Path" with some checking to see if it includes and
> executable
> > works fine if the sub-VI that uses it is in the same folder as the top
> level
> > VI or executable. Now I'd like to locate my sub-VI in a utility folder
> but
> > it no longer points me to the top level folder that I am interested in.
> > I'll attach my sub-VI for reference.
> >
> >
> >
>
>



[Attachment VI or Application Directory.vi, see below
]

[Wiebe@CARYA]

Very nice! It's scary how it looks like the VI I've made for it (I didn't
send it, it's better to first let someone try). Lot's of labview programmers
don't use error handling and 4X4X4 connector pane.

Two (very minor) things;

The VI will only work when run from the main (and this can not be avoided).
So when debugging be aware. I usually put the result in a gli buffer, so
when the main was run once, the buffer still gives the correct result.

The .llb and .exe should be .exe^ and .llb^. It will almost never occur, but
a windows file name could be application.llb.exe, or application.exe.vi.
Anyway, it's not really important (but using ^ is still an interresting
feature).

Regards,

Wiebe.

"Neal" wrote in message news:405734d9@newsgroups....
> That worked like a charm, thanks! I was already stripping an extra path
if
> the VI was located inside an executable but I changed it to strip if
inside
> an llb like you suggested. I attached the updated VI with my copyright
> removed so anyone can use it. It is really hand for building relative
paths
> to things like INI files and data folders! It also lets you know if the
VI
> is running inside and application (executable). This is handy because
> shutting down is often handled differently when you are running in an
> application versus the LabVIEW development environment.
>
> "Wiebe@CARYA" wrote in message
> news:4056ce06@newsgroups....
> > Hi,
> >
> > Have a look at the Call Chain function (in Application Control). This
gets
> > you the name of the top level vi (in the last element of the array).
Open
> a
> > reference to this VI, get its path, strip the name, and see if it's in a
> > library. Sometimes you'll need the path including a library (when
opening
> a
> > vi) and sometimes you don't (when opening a support file, like an ini
> file).
> >
> > Regards,
> >
> > Wiebe.
> >
> >
> > "Neal" wrote in message news:405637ce@newsgroups....
> > > Does anyone know how to calculate the path to the folder that a top
> level
> > VI
> > > or executable is in from a sub-VI that could be located anywhere?
> > >
> > > "Current VI's Path" with some checking to see if it includes and
> > executable
> > > works fine if the sub-VI that uses it is in the same folder as the top
> > level
> > > VI or executable. Now I'd like to locate my sub-VI in a utility
folder
> > but
> > > it no longer points me to the top level folder that I am interested
in.
> > > I'll attach my sub-VI for reference.
> > >
> > >
> > >
> >
> >
>
>
>

[JeanPierre]

Hi,

I have attached a modified version of your VI that has few advantages over your version.

1) There is an application property that tells if it's a build application. It is platform independant since it doesn't assume any specific file extension.

2) Again, the test for a directory doesn't depend on a specific file extensions: the File/Directory Info node is used.

3) Since the returned path is often used to build other paths, I've included an optional relative path input that is build with the output path. This gives much cleaner diagrams.

In a build application, there is an option to build using an external llb, located by default in the directory "data/data.llb". This VI will then return the "data" direc
tory where it will be located. If you really want the application directory, you should use the application property "App.dir" which outputs the directory where the application is located. Maybe the VI should be modified to return App.Dir when called from a build application.

[nealpederson]

I like the platform independency and the relative build path of your VI but
you removed what I was originally trying to accomplish (finding the
directory of the top-level VI, not this VI). I integrated your changes with
the Call Chain function that Wiebe told me about and attached the latest
copy.

"Jean-Pierre Drolet" wrote in message
news:506500000005000000DA6A0100-1079395200000@exchange.ni.com...
> Hi,
>
> I have attached a modified version of your VI that has few advantages
> over your version.
>
> 1) There is an application property that tells if it's a build
> application. It is platform independant since it doesn't assume any
> specific file extension.
>
> 2) Again, the test for a directory doesn't depend on
a specific file
> extensions: the File/Directory Info node is used.
>
> 3) Since the returned path is often used to build other paths, I've
> included an optional relative path input that is build with the output
> path. This gives much cleaner diagrams.
>
> In a build application, there is an option to build using an external
> llb, located by default in the directory "data/data.llb". This VI will
> then return the "data" directory where it will be located. If you
> really want the application directory, you should use the application
> property "App.dir" which outputs the directory where the application
> is located. Maybe the VI should be modified to return App.Dir when
> called from a build application.



[Attachment VI or Application Directory.vi, see below]