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.

[cy...]

@Kosta: thanks for the answer for the old question, but this idea seemed to merge the constant, build and name into 1 node. perhaps calling it "build from directory" would be more appropriate? think we can preserve the ..\ for the relative function for this node

visually, can also consider having the drop list next to the path like:

[user desktop] \ foo\bar.txt = c:\users\user\desktop\foo\bar.txt

but it made me wonder how this idea handle relative paths?

[user desktop] \ ..\foo\bar.txt = c:\users\user\foo\bar.txt 🤔

are we creating new user in the above example?

[Kosta]

@CY, Thank you for the comments.

I appreciate your feedback on the name, because the output of the node is an absolute path. I now believe we'd need a better name than what I proposed. I was hoping for words that convey what you get as opposed to how it works, which is why I'm not sold on "build from directory". I don't have a name I am happy with at this time.

I agree that supporting ..\ makes sense - I want to go up from Current VI's Directory reasonably often.

I went with vertical placement rather than horizontal because I ordinarily write VIs that fit in one screen, and I often struggle with horizontal space, and only rarely with vertical space. Having said that, I see how fully horizontal layout would work fine for short paths, like this one:Short Path

In an ideal scenario, users would be able to size the rectangle to their liking, with the minimum width set so you see the entire pull-down. For a long path, we may have something like this:

Long Path, Full

I could see abridged paths (with ... in the middle) work well, like this:Long Path, Abridged

For your example

[user desktop] \ ..\foo\bar.txt = c:\users\user\foo\bar.txt 

The node would return the absolute path shown, which is consistent with what Build Path function would do. The node would not be creating new directories - that would be up to the code that uses the node.

[AristosQueue (NI)]

> Note that the path 3 and path 4 are identical.

They are not be identical.  If the VI is at "c:\x.vi", then #3 is "c:\x.vi\foo\bar.txt" and #4 is "c:\foo\bar.txt".

> but it made me wonder how this idea handle relative paths?

The only thing you ever put into the node would be relative paths. "foo\bar.txt" is a relative path. There's nothing special about adding ".." to the text. It would still be a relative path and would still work the same.

If you want to see that in action, drop a path control on a panel and then type this into it:

c:\blah\foo\..\bar.txt

The text will immediately update to

c:\blah\bar.txt

So if Kosta's node allows you to type the "..", it'll work itself out when those are combined. The node doesn't need any special code.

[AristosQueue (NI)]

As for a name, how about "Context-Sensitive Path"?

I would not put the word "Constant" into the node's name because it cannot be constant folded (it's computed at run time every time, not built into the binary code). Use of the term "Constant" is something I've recently become more sensitive to. I used to be fine with it for things that were constant for the lifetime of the program (i.e., a node that computes its value on first call and returns the same value thereafter), but after a couple performance debugging adventures, I've decided that nodes in the palettes should only use the term if they are actually constants.

[AristosQueue (NI)]

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.

[Kosta]

@AristosQueue, the code for path 3 strips the leaf in the VI path name (the VI file name) before appending foo/bar.txt to it, so if the VI is at "c:\x.vi", path 3 will be "c:\foo\bar.txt" just like path 4. Am I overlooking something?

I agree that the only thing you'd ever put in the node would be relative paths, and that .. would not require special treatment.

I appreciate that the word "constant" doesn't convey what's going on here, and that's why I would prefer not to have it in the name of the node. I agree that naming things is hard. The name for this node is a fine example of such difficulty, especially since the function of the node is relatively simple.

[cy...]

@AQ: sorry, I misquoted the constant, it should have been:

[user home] \ ..\foo\bar.txt = c:\users\user\..\foo\bar.txt = c:\users\foo\bar.txt? wouldn't that cause a problem, especially if given permission to run as admin? 🤔

anyways, maybe we can consider something like a new pallet function to upgrading the existing "get system directory.vi" to "get system directory 2.vi"* with a built-in "build path" function and an optional terminal "name or relative path"?

*more suitable name for the function and its terminals are required

[AristosQueue (NI)]

Kosta- I'm the one who missed something... I didn't see that Strip Path node in #3. I even coded the darn thing into LabVIEW to check it, and still didn't consciously register that Strip Path node. Sorry for the confusion. 

[AristosQueue (NI)]

cy wrote:

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

Or it could be exactly what the programmer was trying to do, especially if given explicit permission to run as admin. We don't know the programmer intent in constructing such a path. Forget this node... such a path could be typed in explicitly today. It is the job of all the downstream functions to check the legitimacy of paths, the permissions of files, etc. The path construction functions should construct the paths requested.

[wiebe@CARYA]

cy wrote:

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

Parts of the program can have admin rights, while other parts don't. You can even give the program rights after a function fails without the rights. Not a good idea per se, but possible.

A value that gives wrong results doesn't mean the value is wrong.