FolderItem.NativePath delimiters (or examples) per platform

Haha, well I’m nowhere near your league, tot sicher! :smiley: Your articles and source code resources have been invaluable to me. I learned programming mostly on a Commodore 64, then came back to programming seriously later on a Mac. My degrees are in music and I split my time between music and coding.

[quote=226308:@Aaron Hunt]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 [/quote]

You don’t need it in Xojo, since obviously you created it :wink:

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

On windows, does the nativepath show the long name or the short name of the file/folder??

I don’t know what you’re doing with this information, but in almost every case where I’ve been tempted to do some path-twiddling, there has been a better solution that does not require it. YMMV.

+1

I would use GetFolderItem(somenativepath, FolderItem.PathTypeNative), then it is so easy to go Child or Parent and be done with pesky separators :slight_smile:

I strongly recommend using folderitems. But if you absolutely want to use paths, for instance to use in a shell or to store Shell is the short name. I have personally never used NativePath. Sometimes shellPath. Most of the time FolderItems. Never had any headaches :wink:

[quote=226331:@Thomas Tempelmann]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.[/quote]

The reason I don’t use string.split is because Xojo still does not offer string.join

Trim I have used both ways, but In that example my brain was in the other mode because of the way I used split (which is because of the way join works), so it seemed more consistent when coding.

Anyway, I have instead decided to make these methods extend the Folderitem class using your suggested names, and that does make more sense. I will put the code in the original post so it can be found easily.

Cheers,
Aaron

Split and Join go hand in hand, and both are certainly available. See:

http://documentation.xojo.com/index.php/Join

Sorry but you’ve missed the point. Join has no OO version. You can’t write string.join in Xojo. You CAN write string.split. Because you CAN’T write string.join, then I DON’T write string.split, because I like these two partner methods to look the same.

Hmm, it seems I can’t edit the original post, can only select which post answers the question, so let me first quote Thomas Tempelmann who answered the question:

[quote=226320:@Thomas Tempelmann]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.[/quote]

Now let me show my methods which extend Folderitem to get what I’m looking for. Put these in a Global module.

Function NativePathDelimiter(Extends f as FolderItem) As string
  #if TargetMacOS then
    return "/"
  #elseif TargetWin32 then
    return "\"
  #elseif TargetLinux then
    return "/"
  #endif
End Function
Function NativePathParts(extends f as FolderItem, removeEmptyParts as Boolean = True) As string()
  // return an array of strings from a NativePath (x-plat)
  dim pathParts() as string
  if f <> Nil then
    ' parse the path
    pathParts() = f.NativePath.split( f.NativePathDelimiter )
    ' remove empty parts?
    if removeEmptyParts then
      for j as integer = pathParts.Ubound DownTo 0
        if pathParts(j).trim = "" then pathParts.remove j
      next
    end if
  end if
  return pathParts()
End Function

Thomas Tempelmann may notice that above I even used OO string.split and string.trim :wink: Thank you everyone for your help.

Consider you’re given a random NativePath called GivenNativePath as a string. There is no FolderItem connected to it. You can do this:

dim f as FolderItem = GetFolderItem( GivenNativePath, Folderitem.PathTypeNative )

And then work with the result.

The problem is, this does not work in cases where the path is Nil. Then you lose the ability to work with it at all.

I want to be able to work with the path regardless of whether it is Nil or exists, and the only way to do that is by looking at the path as a string.

No matter if the folderItem is nil because the path does not exist, it can be used with Parent and child.
When a FolderItem is composed and the file is not created, of course it is nil.

For instance, this does not trigger any error, while tagada.txt is pure fantasy :

dim f as FolderItem = GetFolderItem( "/Users/Mitch/Desktop/tagada.txt", Folderitem.PathTypeNative ) system.DebugLog f.name // gives tagada.txt system.DebugLog f.ShellPath // Gives /Users/Mitch/Desktop/tagada.txt system.DebugLog str(f.exists) // Gives False

This gives exactly the same results as

dim f as FolderItem = SpecialFolder.Desktop.child("tagada.txt") system.DebugLog f.name system.DebugLog f.ShellPath system.DebugLog str(f.exists)

If the folderitem is nil, there is no parent. Your example produces a non-nil folderitem.

Fair enough.

That is the whole point. GetFolderItem does not produce nil folderitems, even with completely invalid paths.

I would really love to know how a path can be nil, since it is a string anyway. Note that even an empty string produces a working FolderItem.

Whatever.

[quote=226514:@Michel Bujardet]That is the whole point. GetFolderItem does not produce nil folderitems, even with completely invalid paths.

I would really love to know how a path can be nil, since it is a string anyway. Note that even an empty string produces a working FolderItem.

Whatever.[/quote]

Nope, that’s simply not true.

  dim path as string = "chocolate/cake/beans/rice/carrots/and/peas.mp3"
  dim f as FolderItem = GetFolderItem( path, FolderItem.PathTypeNative )
  MsgBox f.name
  MsgBox f.ShellPath
  MsgBox str( f.exists )

Fails with a Nil folderitem. The point is these paths are coming from a foreign file and I don’t know what’s in the path string, but I want to be able to work with whatever is there. That is the whole point, and the reason your way does not work.

[quote=226539:@Aaron Hunt]Nope, that’s simply not true.

  dim path as string = "chocolate/cake/beans/rice/carrots/and/peas.mp3"
  dim f as FolderItem = GetFolderItem( path, FolderItem.PathTypeNative )
  MsgBox f.name
  MsgBox f.ShellPath
  MsgBox str( f.exists )

Fails with a Nil folderitem. The point is these paths are coming from a foreign file and I don’t know what’s in the path string, but I want to be able to work with whatever is there. That is the whole point, and the reason your way does not work.[/quote]

As I said, whatever. It is your karma. Work with invalid paths to your heart content :slight_smile:

The path itself cannot be nil, but an impossible path will return nil from GetFolderItem. Every segment in the path must exist except the last one. Otherwise, you get nil.

Since Aaron is dealing with stored paths, if one of the intervening folders is moved, renamed, or deleted, then that path will yield a nil FolderItem.