Jump to content

Programming for Separator Character in File Paths between platforms


dhakkan

Recommended Posts

Hello,

 

I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS.

 

Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.)

 

I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Thank you.

 

Link to comment

Hello,

 

I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS.

 

Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.)

 

I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Thank you.

 

There are two VIs in "vi.lib\Advanced String\"

  • Path To Command Line String.vi
  • Command Line String To Path.vi

These take in to account the platform separator when converting to and from strings and paths. Use those instead of the palette primitives.

Edited by ShaunR
Link to comment

Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Not exactly a constant but a VI that returns the path separator:

 

vi.lib/Utility/sysinfo.llb/Get File System Separator.vi

 

Edited by candidus
  • Like 1
Link to comment
  • 2 weeks later...

At the outset, my apologies for the delay in acknowledging your responses - a holiday trip and getting under the weather did not help...

 

 

 

Not exactly a constant but a VI that returns the path separator:

 

vi.lib/Utility/sysinfo.llb/Get File System Separator.vi

 

 

 

Thanks! that helps. A clever way to get the separator, though!

 

There are two VIs in "vi.lib\Advanced String\"

  • Path To Command Line String.vi
  • Command Line String To Path.vi

These take in to account the platform separator when converting to and from strings and paths. Use those instead of the palette primitives.

 

Am confused by 'Command Line String To Path.vi'. Under the wrapper it seems to call the native 'String to Path' function except for a Mac OS 32-bit application. In this exception case, not-a-path constant is returned. That doesn't seem to help solve my problem.

 

Now, I'm using the solution candidus provided to build the necessary relative path.

 

Thanks! folks, for your help; and a very Happy New Year to one and all.

Link to comment

At the outset, my apologies for the delay in acknowledging your responses - a holiday trip and getting under the weather did not help...

 

 

Thanks! that helps. A clever way to get the separator, though!

 

 

Am confused by 'Command Line String To Path.vi'. Under the wrapper it seems to call the native 'String to Path' function except for a Mac OS 32-bit application. In this exception case, not-a-path constant is returned. That doesn't seem to help solve my problem.

 

Now, I'm using the solution candidus provided to build the necessary relative path.

 

Thanks! folks, for your help; and a very Happy New Year to one and all.

 

The VI "UNIXPathStringToPath" is an unused placeholder on windows. It is replaced with a platform specific implementation when loaded on Mac.

  • Like 1
Link to comment

http://themacview.blogspot.com/2014_08_01_archive.html

 

 

LabVIEW 2014, First 64-bit Version for Mac POSIX Paths
Screenshot+2014-08-04+11.18.47.png
This was long overdue. Paths in 32-bit are formatted in HFS Classic format. 64-bit uses the more common POSIX paths. It's mostly showing slash (/) instead of colon (:) between path elements (although there is more to it than that). 
 
There is also a little bit of magic that happens in 64-bit when a path in a string is converted to a path type that allows either format, and then converts it into POSIX style. You can try this by copying the path from the 32-bit path indicator and paste it into the 64-bit indicator. Once focus leaves the indicator, the path will be converted to POSIX format (it's pretty fun to watch).
 
Screenshot+2014-08-04+11.29.03.png
This magic also happens when using the String to Path primitive. You can have a string of either format and it will convert it to a POSIX path. This makes it easier to transition between 32-bit and 64-bit as you are testing your VIs in 64-bit.
Screenshot+2014-08-04+11.34.43.png
Some other VIs that assist in dealing with paths between 32-bit and 64-bit are Path to Command Line String.vi and Command Line String To Path.vi inProgramming -> String -> Path/Array/String Conversion palette. These VIs are helpful in building a path that can be used in System Exec.vi or system shared libraries in a cross-platform manner. They have actually existed in LabVIEW since before 2009, but are added to the palettes now to assist in transitioning between 32-bit and 64-bit on Mac.
 
Screenshot+2014-08-04+11.39.52.png
Another path related VI that is helpful for Mac users is Executable Path To Command Line String.vi. This VI helps in getting the path to the executable in an app.
Screenshot+2014-08-04+11.41.19.png
This is particularly helpful writing cross platform code that will launch LabVIEW built apps, LabVIEW itself, or other GUI applications. Windows and Linux just take the path to the EXE. On Mac, the .app is really just a folder. This VI will give you a path to the executable you can call from System Exec.vi, in a cross-platform way. This VI did not make the cut for the palettes, but you can find it in vi.lib/AdvancedString.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.