Symbolic path

[sabri.jatlaoui]

Hi RavenFan,

You should read my first post more closely.

This path is as default set into the VI Search Path on the Paths page.

Regards.

[Norbert_B]

Can you please attach code showing how you refer to <topVI>?

I assume that you have a major confusion here.

The configuration of the symbolic path in the LV DevEnv serves only internal purposes to find static dependencies.

Read: If you put a subVI (saved on disk) into its caller, which is a static dependency, LV stores the path to that subVI in the caller. If the initial part of the path matches one of the symbolic path, LV will store the symbolic path instead of that absolute path information. This enables the project to be moved to different systems, where the project itself or maybe LV is found 'elsewhere' (e.g. drive letter d instead of c). The (local) configuration of the symbolic path ensures that the individual system can find these static dependencies when loading a top level VI.

Symbolic (aka pseudo) paths are not available for dynamic dependencies or for running code in the RTE (e.g. as EXE, PPL, ...).

[Yamaeda]

What do the resulting path look like? I would you're looking a folder too high and assume the previous comment of using app-path is the solution. If you're using a compiled .exe that's usually the solution. 🙂

/Y

[rolfk]

---

@sabri.jatlaoui wrote:

Hi RavenFan,

You should read my first post more closely.

This path is as default set into the VI Search Path on the Paths page.

---

You know, VI search Path is named that way because it is the list of paths LabVEW will search for VIs (and controls which are internally also a sort of VI) when it can't find them at the location the referencing VI says they should be, but not for documentation files!

And Norbert, no, LabVIEW does not replace a path component with every possible symbolic path when storing VIs. This is only true for the well known VI directories such as <userlib>, <instrlib>, and <vilib>. <topvi> is a dynamic location that will change depending on the actual top level VI that is running at that moment and a pretty bad location to reference a VI to. <osdatadir> is similar as this would be user specific and therefore a bad location to store into a VI that has the possibility to be loaded under a different user account or machine.

<topvi> and <foundvi>, and likely also <osdatadir>, are only relevant for the VI search paths, not as explicit references inside path controls.

[Norbert_B]

---

@rolfk wrote:
[

---

...] <topvi> is a dynamic location that will change depending on the actual top level VI that is running at that moment and a pretty bad location to reference a VI to. [...]

---

 Still, it is a symbolic path as basis to build an absolute path out of the relative path information stored in the calling VI.

You are correct in that that the <topvi> symbolic path changes depending on the VI you load while <vilib>, <userlib> and <instrlib> are static per system (defined by installation location).

EDIT: I think <topvi> can be best understood as "macro" for building absolute paths to vi sources. The value of the macro changes dependent on the active top level vi internally in LV.

[sabri.jatlaoui]

Hi Rolfk,

Thank you for the response. 

I need the <TopVI> symbolic path as I need an relative path  associate to a project. As I already written, I want to commit a project with an associate Html documentation files. with my project open, I was able to use all symbolic path exept this one. 

Of course it's in dev environment that I need it to work.

As I can load those documentation files using <osdatadir> and the help say " this symbolic path when setting the VI Search Path on the Paths page of the Options dialog box."

I presume that I can use <topVI > the same way.

[rolfk]

You know what a presumption is. It is often wrong and the fact that <osdatadir> works is no guarantee that the others would work the same. The documentation says nothing about that they would work, and to presume that because <osdatadir> does, this means the others will do is just that, an assumption on your side.

It doesn't and I see no reason why it should. <topvi> is not a static location! It only would work if you ALWAYS use your library from the same top level VI, which is such a restrictive requirement, that it seems like a pretty useless feature, and I'm sure the LabVIEW developers feel the same, hence you can want all day long that it works like that, but it will not do so!

[sabri.jatlaoui]

"The documentation says nothing about that they would work, and to presume that"

I think you don't get wrong. the documentation explain how it should work

In my project <topvi> is supposed to give me the path of the higher VI of the project hierarchy. If it's exist it could be used.

My question was't if it's a good way of calling a file. It was How to used it.

[Norbert_B]

Re-reading your original question and the link to the help you refer to, i think you are discussing about this text:

[...]or the Help path on the Documentation page of the VI Properties dialog box. To use this symbolic path, enter <userlib>:\ then the filename or path and filename to the help file.[...]

If you read that help text carefully, you will see that only three symbolic paths do have this documentation related description:

<userlib>, <instrlib> and <helpdir>.

<vilib> doesn't show that remark as you should not place custom stuff into vi.lib EDIT: But it works....

The others are not listed as they are not meant for storing documentation stuff by symbolic paths.

So all in all it seems that there should be a CAR against <osdatadir> and <vilib> that it does work and draw incorrect expectations. Or, if <osdatadir>, <vilib> is meant to work like that, there should be CAR against the documentation.

However, there is not a single indication that <topvi> should work at all.

[sabri.jatlaoui]

Hi Norbert,

Thank you for the reply.

actually, looking at the Documentation Page (VI Properties Dialog Box)

"Help path—Contains the path or symbolic path to the HTML file or to the compiled help file you want to link to from the Context Help window. If this field is empty, the blue Detailed help link does not appear in the Context Help window, and the Detailed help button is dimmed. You also can use the Help:Document Path property to set the help path programmatically."

Shouldn't be working. with <topVI> symbolic path ?