OS X path name delimiter question

i used path names using AbsolutePath in RealStudio (2013) and am in the process of updating my app to the latest Xojo 2014. It appears that the AbsolutePath() method has been deprecated to instead use NativePath(). This makes sense to me since on OS X, seeing pathnames being passed around with colons (:slight_smile: as folder delimiters is, I assume, “old news.”

I have a question that when setting the FolderItem to create a file, I’m concatenating path and file names and coming up with all sorts of strange behavior (a combination of right slashes and colons like “Macintosh HD:Users:Kenw:Dropbox:PSM Projects:Spresso Backup:Master:App:/Users/Kenw/Desktop/Spresso 2-00-00.log” in the Absolute path property and then “/Users/Kenw/Dropbox/PSM Projects/Spresso Backup/Master/App/:Users:Kenw:Desktop:Spresso 2-00-00.log” in the NativePath.

Yikes, any advice? I’m sure I’m doing something really lame. Colon delimiters (":") aren’t going to be supported in the future by Xojo, right?

thanks,
Ken

[quote=99471:@Howard Whitaker]i used path names using AbsolutePath in RealStudio (2013) and am in the process of updating my app to the latest Xojo 2014. It appears that the AbsolutePath() method has been deprecated to instead use NativePath(). This makes sense to me since on OS X, seeing pathnames being passed around with colons (:slight_smile: as folder delimiters is, I assume, “old news.”

I have a question that when setting the FolderItem to create a file, I’m concatenating path and file names and coming up with all sorts of strange behavior (a combination of right slashes and colons like “Macintosh HD:Users:Kenw:Dropbox:PSM Projects:Spresso Backup:Master:App:/Users/Kenw/Desktop/Spresso 2-00-00.log” in the Absolute path property and then “/Users/Kenw/Dropbox/PSM Projects/Spresso Backup/Master/App/:Users:Kenw:Desktop:Spresso 2-00-00.log” in the NativePath.

Yikes, any advice? I’m sure I’m doing something really lame. Colon delimiters (":") aren’t going to be supported in the future by Xojo, right?

thanks,
Ken[/quote]

My biggest recommendation is to not concatenate paths but rather use FolderItem.Child, which will do ‘the right thing’. As the framework having support for HFS-style removed, it’s not happening any time in the foreseeable future.

Thanks, Joe.
I guess I’m wanting to know which delimiter is smart to use and display for full paths. If I’m not mistaken, SpecialFolder.AbsolutePath would return a character string with a “:” (or “” for Windows) at the end. That clearly distinguishes a folder path from a file. Now it appears that SpecialFolder.NativePath() doesn’t append a “:” to the string. If I’m given a fullpath, is it your sense that I should split it down and perform a series of .Child() calls?

or use GETFOLDERNAME

[quote=99499:@Howard Whitaker]Thanks, Joe.
I guess I’m wanting to know which delimiter is smart to use and display for full paths. If I’m not mistaken, SpecialFolder.AbsolutePath would return a character string with a “:” (or “” for Windows) at the end. That clearly distinguishes a folder path from a file. Now it appears that SpecialFolder.NativePath() doesn’t append a “:” to the string. If I’m given a fullpath, is it your sense that I should split it down and perform a series of .Child() calls?[/quote]

If you’re given a full path, you should create it with the FolderItem constructor and the relevant constant (PathTypeNative, etc). In terms of displaying a path to a user, generally you shouldn’t – though obviously it depends on the kind of software you’re writing. As for the lack of a trailing separator on NativePath, nobody put forward a decent case for it during the beta cycle and it would cause disk IO to fetch that information.

I convert everything to “/” and use FolderItem.PathTypeShell. If I write for Windows as well as Linux and OS X, I create a dynamic string called PathSep and set it to “/” on Linux and OS X and “” on Windows. I then do a ReplaceAll call in the #if TargetWin32 … #else#endif block that I use when setting up file access.

The key to success here is to be sure to wrap that Path string in double quotes so that special characters are handled properly:

“/Library/Application Support/BRU PE/Catalogs”

Otherwise, that example might end up chopped into three items because of the spaces.

[quote=99534:@Tim Jones]I convert everything to “/” and use FolderItem.PathTypeShell. If I write for Windows as well as Linux and OS X, I create a dynamic string called PathSep and set it to “/” on Linux and OS X and “” on Windows. I then do a ReplaceAll call in the #if TargetWin32 … #else#endif block that I use when setting up file access.

The key to success here is to be sure to wrap that Path string in double quotes so that special characters are handled properly:

“/Library/Application Support/BRU PE/Catalogs”

Otherwise, that example might end up chopped into three items because of the spaces.[/quote]

This should work fine most of the time, except when you have spaces in folder names, which must be escaped in Mac shellpath and not in Windows. So on top of setting the hierarchy separator, you also have to monitor space characters, right ?

All good advice. Whew, looks like I have some work to do.

With my prior RealStudio work, I abstracted file primitives (actually a class) that takes care of handling files and folders regardless of OS (Windows and OS X) and before I simply used the appropriate (":" or “”) path delimiter. I do need to keep track of full path names since I reference folders and files outside of where the app runs (the app manages file backups and versioning).

And, Joe, regarding the trailing delimiter in the SpecialFolder example that isn’t similarly formed between AbsolutePath() and NativePath() is easy to accommodate!

Thanks, everyone!

Ken

by the way, in one of my earlier comments, I said this:

That clearly distinguishes a folder path from a file. Now it appears that SpecialFolder.NativePath() doesn’t append a “:” to the string.

I meant to say:
That clearly distinguishes a folder path from a file. Now it appears that SpecialFolder.NativePath() doesn’t append a “/” to the string.

[quote=99543:@Michel Bujardet]This should work fine most of the time, except when you have spaces in folder names, which must be escaped in Mac shellpath and not in Windows. So on top of setting the hierarchy separator, you also have to monitor space characters, right ?

[/quote]
That’s why I surround them in quotes. I then use:

thePath = "/Library/Application Support/BRU PE/Catalogs" f = GetFolderItem(thePath, FolderItem.PathTypeShell)

Or, if I’m passing to a shell operation:

theShell.Execute "cat """ + thePath + """ | grep -H ""Some Text To Search For"""

Works correctly every time.

Neato! And thanks, Joe–I honestly didn’t know about PathTypeNative new parameter in the FolderItem constructor until you mentioned it. Dumb question, but I assume that based on setting PathTypeNative during construction that as you perform other operations with FolderItem, that the object “remembers” to recognize the native path delimiters (like “/” for OS X or “” for Windows)?

Since PathTypeNative is optional second parameter, what would you do if you don’t wish to start out with a path when constructing the FolderItem? Can you pass a “” for the first parameter without messing things up?

Ken

[quote=99598:@Howard Whitaker]Neato! And thanks, Joe–I honestly didn’t know about PathTypeNative new parameter in the FolderItem constructor until you mentioned it. Dumb question, but I assume that based on setting PathTypeNative during construction that as you perform other operations with FolderItem, that the object “remembers” to recognize the native path delimiters (like “/” for OS X or “” for Windows)?
[/quote]
No, it uses some internal representation of the folder hierarchy. (It could be absolute/native path, but we don’t need to know about that detail.) You can pull any kind of path back out.

[/quote]Since PathTypeNative is optional second parameter, what would you do if you don’t wish to start out with a path when constructing the FolderItem? Can you pass a “” for the first parameter without messing things up?
[/quote]
It isn’t necessary to provide a path type. GetFolderItem("") still returns the folder that the app is sitting in, just like always. You don’t have to tell the folderitem what type of path to use.