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.
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.
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.
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.
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
#elseif TargetWin32 then
#elseif TargetLinux then
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
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
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
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