Symbolic path: Difference between revisions
No edit summary |
|||
| Line 39: | Line 39: | ||
''symbolic path'' are not generally encountered. They are used mostly under the hood of LabVIEW, for example, when using the Application '''Linker:Read Info From File''' and '''Linker:Write Info To File''' methods. | ''symbolic path'' are not generally encountered. They are used mostly under the hood of LabVIEW, for example, when using the Application '''Linker:Read Info From File''' and '''Linker:Write Info To File''' methods. | ||
== Auto update of symbolic paths == | |||
If you have a VI linked to another VI inside a symbolic path LabVIEW will automatically store the path symbollically. Here's the following use case: | |||
Syppose you want to build a LabVIEW tool that resides under the Tools menu but is also accesible via the user.lib palette. What you can do is create a set-up upon built like this: | |||
Built | |||
\-Tools | |||
\-Menu VI | |||
\-user.lib | |||
\-Actual VI | |||
When you copy the contents of ''Built'' to the LabVIEW folder the ''Menu VI'' will have a relative paht like ''..\user.lib\Actual VI'' when you do a resave of the ''Menu VI'' the path will be changed to an absolute path ''<userlib>\Actual VI''. Now you can move the ''Menu VI'' around without breaking it. | |||
== When Using Modules (FPGA, RT, etc) == | == When Using Modules (FPGA, RT, etc) == | ||
Revision as of 06:28, 9 November 2007
When files are located beneath certain special folders, callers that link to these files will link to them using a symbolic path, rather than an absolute or relative path. The symbolic path will be relative to the special folder. The following table lists these special folders and their symbolic path:
| symbolic path | description | actual path |
|---|---|---|
| <userlib> | User Libraries | <LabVIEW>\user.lib |
| <vilib> | NI Libraries and Addons | <LabVIEW>\vi.lib |
| <instrlib> | Instrument Drivers | <LabVIEW>\instr.lib |
| <help> | Help Files | <LabVIEW>\help |
| <menu> | Palette Menus | <LabVIEW>\menus |
Note that some of these can have the actual path changed by changing the settings in Tools>>Options. The whole point of the symbolic path is to indicate "load from whatever location this path is currently defined to be."
For example, if you have a VI located in the following location:
<LabVIEW>\user.lib\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi
Callers will link to this VI using the following symbolic path:
<userlib>\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi
symbolic path are not generally encountered. They are used mostly under the hood of LabVIEW, for example, when using the Application Linker:Read Info From File and Linker:Write Info To File methods.
Auto update of symbolic paths
If you have a VI linked to another VI inside a symbolic path LabVIEW will automatically store the path symbollically. Here's the following use case:
Syppose you want to build a LabVIEW tool that resides under the Tools menu but is also accesible via the user.lib palette. What you can do is create a set-up upon built like this:
Built \-Tools
\-Menu VI
\-user.lib
\-Actual VI
When you copy the contents of Built to the LabVIEW folder the Menu VI will have a relative paht like ..\user.lib\Actual VI when you do a resave of the Menu VI the path will be changed to an absolute path <userlib>\Actual VI. Now you can move the Menu VI around without breaking it.
When Using Modules (FPGA, RT, etc)
A symbolic path may resolve to different actual files on disk depending upon which target the VI is loaded into. So a VI that is written to use <vilib>\a.vi may use <labview>\vi.lib\a.vi when loaded for the desktop target, but may use <labview>\vi.lib\fpga\a.vi when loaded for the FPGA target.