FolderItem.NativePath delimiters (or examples) per platform

I need to parse a NativePath string correctly on multiple platforms. The LR appears to be no help.

It would be helpful if someone would please update the LR page for Folderitem.NativePath with example strings of a path on each platform, showing the correct path delimiters.

Does anyone have the information handy?

Thank you.

Why are you using NativePath instead of Parent/Child?

There are cases in which working with an actual folderitem object hierarchy is not possible. This is one. The paths are stored in a “master document” file as strings (64-bit encoded inside an XML tag). They are paths to source files referred to by this"master document", and they need to be reconstructed upon loading the “master document” file. I check the paths to see if a valid folderitem exists, and if not, prompt the user to find the file. I would like to be able to parse the paths in order to handle this intelligently.

… unless it IS possible to use Parent/Child here, and I’ve misunderstood something about how these paths work?

What’s the problem with using split with “:” for MacOS and “” for Windows?

Well, right, this is what I want to do and what I asked about.

So the answer is, the delimiter is “:” on Mac and “” on Windows? And what is it on Linux?

And why can’t this be in the LR with a simple example?

… Mac appears to be “/”, not “:” … this is why I’m asking. Why is it impossible to find this basic information in the LR?

Because they’re OS standard and not really part of Xojo? If you saved them as NativePath, then try to reconstitute a FolderItem with GetFolderItem(thePath, FolderItem.PathTypeNative). If that is Nil or not Exists, then prompt for it.

This is basic information for every programmer. You do a NativePath for every OS and you have the necessary information in 10 seconds.

That’s what I’m doing. I just want some basic information about the path to work with. Something as simple as getting the filename. By knowing the $%^& delimiter. I don’t always have access to every platform to run a quick msgbox and see the result. It’s idiotic that this information isn’t in the LR under NativePath.

Is there a function like this already in Xojo? If not, there should be.

Function GetNativePathDelimiter() As string
  #if TargetMacOS then
    return "/"
  #elseif TargetWin32 then
    return ?
  #elseif TargetLinux then
    return ?
  #endif
End Function

Exactly. So could someone at Xojo please do that and put it in the LR?

Thanks.

This one line function

Function FolderDelimiter() As String Return Right(SpecialFolder.Documents.NativePath, 1) End Function

Seems to be xPlat? I’ve only tested on Windows, but I am assuming it will be valid across all platforms without pragmas, but please enlighten me if not.

[quote=226311:@Wayne Golding]This one line function

Function FolderDelimiter() As String Return Right(SpecialFolder.Documents.NativePath, 1) End Function

Seems to be xPlat? I’ve only tested on Windows, but I am assuming it will be valid across all platforms without pragmas, but please enlighten me if not.[/quote]

Thanks, but I don’t think that works. From the LR:

So can’t count on the path ending in the delimiter.

No, it doesn’t work. I ran this on Mac and got back the letter “s”

msgbox Right(SpecialFolder.Documents.NativePath, 1)

Do these delimiters change from one OS version to another? Like, Windows 8 has a different character than Windows 10? Seems highly improbable! That’s the only reason I could imagine for not putting them in the LR. Even then, a simple chart would do, and a GetNativePathDelimiter function could just check the OS version to return the right delimiter.

The path separators are constant between OS versions.

On OSX, when you use a NativePath, as well as on Linux, it’s always “/” - that’s commonly called a POSIX path, BTW, as the POSIX standard has defined it that way and is used on both Linux and Unix.
On Windows, you have both “:” (as a driver letter separator) and “”. But Windows may also use paths like this: “\\server\bla\bla”, IIRC.

Beware that a Mac POSIX path may also contain “:” - that’s a normal name character, then. Macs also can use “:” as folder separators, but only with other APIs, eg. when you use AbsolutePath, or when you use classic File manager declares (usually prefixed with FS…). But if you use NativePath, as you should, then don’t worry about this - just assume “/” is the only path separator and accept any other char, including “:”, even the NUL char, as part of the file and folder names.

Okay, great, thank you Thomas!

Now I’ve made two helper functions.

  1. to get the delimiter
  2. to split the path into its parts keeping in mind Windows trailing slash and possible double slashes

Does this all look okay to you?

Function GetNativePathDelimiter() As string
  #if TargetMacOS then
    return "/"
  #elseif TargetWin32 then
    return "\"
  #elseif TargetLinux then
    return "/"
  #endif
End Function
Function GetNativePathParts(thePath as string) As string()
  dim pathParts() as string = split( thePath, GetNativePathDelimiter )
  for j as integer = pathParts.Ubound DownTo 0
    if trim( pathParts(j) ) = "" then
      pathParts.remove j
    end if
  next
  return pathParts()
End Function

It looks like it compiles. Whether it works for your use case I can’t tell because I don’t know what you do with that array you create. Especially since you remove empty “folders”, which would lose information if you had a Windows server path starting with \\.

BTW, naming methods that only return a value with “Get” is not a good style. It’s common practise in Java, but other languages, including Xojo, aren’t encouraging this terminology. A Get is rather used for methods that return ByRef values, along with a Boolean, perhaps, like this:

if GetCoordinates (x, y) then ... end

Instead, name your functions like yours above without Get but name them so that they read well grammatically. So, call them NativePathDelimiter and NativePathParts. Their names alone make it clear they’re not setters but act like values.

Just a suggestion, since you seem to be still learning :slight_smile:

Well, I hope I’ve learned some basic things by now programming since the 1980’s (but there was a good 10 years I didn’t do any programming and things changed a LOT). Anyway, I usually only use “Get” for method names when I also have a “Set”. I’m not totally consistent with it, but I will say I have improved a lot in this area over the past decade. Thank you for the help and good advice!

P.S. naming the methods NativePathDelimiter and NativePathParts doesn’t seem like “good style” to me because those sound like properties to me, but that’s just my personal habit. I don’t have to work with other programmers, so I can do what makes the most sense to me :wink:

1980s? Then you’re still a newbie to me :smiley:

One more thing, since you seem to be stuck with old programming paradigms (I know, I had the same trouble when OO become popular). You can write:

thePath.Split( GetNativePathDelimiter )

Same for Trim.
I find that more readable. You may find that differently, but it’s probably a question of getting used to. Certainly, it’s the “modern” way :wink: