Relative Path Node

[Kosta]

I'd like to work with relative paths at a higher level of abstraction.

I often use path constants in block diagrams, and almost always I need relative paths. I love Browse for Path option on the file path constant. Inconveniently, I end up with an absolute path when I browse like that, then have to manually select the front end of the path, and drop a few other nodes and wires to specify what the path is relative to. The resulting code looks like this:

Four Relative Paths LabVIEW 2019

Note that the path 3 and path 4 are identical.

I would like to see a single node that:

• Lets us specify what the path is relative to,
• Lets us browse for a path like the file constant, and
• Displays relative path without manual editing.

Here is what the code displayed above would simplify to:

Four Relative Paths with New Node

I'd like the base path selection to include options consistent with those from the file palette. One way to do this is to have a shallow hierarchy like this:

• LabVIEW
  • Application Directory
  • Current VI's Directory
  • Default Data Directory
  • Default Directory
  • Temporary Directory
  • VI Library
• System
  • User Home
  • User Desktop
  • User Documents
  • User Application Data
  • User Preferences
  • User Temporary
  • Public Documents
  • Public Application Data
  • Public Preferences
  • Public Cache
  • System Core Libraries
  • System Installed Libraries
  • Application Files
  • Boot Volume Root

This idea is based on the discussion from the Path Constants Relative to the Current VI's Directory Path idea. I'd like to thank AristosQueue and crossrulz for their feedback on that thread.

[Kosta]

cy wrote:

> wouldn't that cause a problem, especially if given permission to run as admin?

I agree with the two comments above - the node should do what it's told, the programmer should write downstream code to deal with the consequences.

[tst]

---

@AristosQueue wrote:

PS: If anyone has a good name for nodes that return values that are constant for the lifetime of the program, and that name is not "static", I'd like to hear it. Naming a node "Current System Color Table" doesn't make it clear that it is not changing during the program's lifetime, and I haven't found any good synonyms of "constant"... "System Color Table Immutable" is weird. As is "Invariable", "Non-Variable", "Fixed". My current favorite is "Computed System Color Table", but I'm not particularly thrilled with it.

Naming things is hard.

---

Lifelong system color table?

I would add it to the weird category, but you might not.

[Kosta]

@AristosQueue wrote:

PS: If anyone has a good name for nodes that return values that are constant for the lifetime of the program, and that name is not "static", I'd like to hear it. Naming a node "Current System Color Table" doesn't make it clear that it is not changing during the program's lifetime, and I haven't found any good synonyms of "constant"... "System Color Table Immutable" is weird. As is "Invariable", "Non-Variable", "Fixed". My current favorite is "Computed System Color Table", but I'm not particularly thrilled with it.

Naming things is hard.

System Color Table for the Lifetime of the Program. I know it's wordy. What else is wrong with it?

[cy...]

@AQ: assigned...?

[wiebe@CARYA]

Isn't this similar to the symbols used in the conditional disabled structures?

Those values are "program lifetime". They are fixed in executables, but that is just because most (all?) current symbols can only change by a recompile. Of course this is not quite the same. If the symbols can change, the CDS isn't going to work for them.

So, maybe "Path symbols", "Path table symbol", "Symbolic system paths table"? Just thinking out loud...