Make It More Obvious that Build Path Can Accept a Relative Path Input

[Darren]

I've had enough!  Your code does not have to look like this:

Or this:

You don't have to wire a string into Build Path's second input!  It can take a relative path just fine!  This is particularly helpful when building relative paths that involve climbing a directory structure.  But it's also useful for building hard-coded folder paths, or even just specifying a file name:

I've seen code that looks like the first two images way too often, so I propose the following:

• Change the name of the second input of the Build Path function to 'relative path or name'.
• Change the default data type of this input (i.e. what it looks like when unwired) to path instead of string.

The function will still work fine with string inputs (so existing code is fine), but this approach encourages developers to actually use the path data type when working with paths. You should kudo this idea if you have ever (1) written code that looks like the first two images, (2) needed to explain to someone that they can wire a path into Build Path's second input, or (3) gotten burned by multi-platform issues when somebody typed path separators into a string wired into Build Path.

[toshas]

Will this idea be included into LV2020 ?

[Darren]

This idea is currently marked as 'In Beta', and the LabVIEW 2020 Beta is the current beta, so it can be reasonably assumed that this idea will likely be included in LabVIEW 2020.

[Darren]

Available in LabVIEW 2020 and later. The 'name or relative path' input on the Build Path function now defaults to a path data type when the function is first dropped. It still accepts a string input if wired.

[toshas]

Wonderful! Thanks!