What is the difference between AbsolutePath and NativePath? I just spent hour and a half debugging a problem with my app upgrade. Connecting to an FTP site worked perfectly in the last release and was failing in the current release. I finally found that the only diff. was at one point I was storing the .AbsolutePath in a cellTag and using that to recover a file. I had routinely changed all AbsolutePaths to NativePaths to comply with directive. Trying to recover that file with .NativePath was producing .exists = False. When I changed the stored var. to f.AbsolutePath, the upload began working once again.
AbsolutePath is old style Mac path on Mac OS X.
NativePath is the native path for each platform.
On Windows and linux both are the same.
you should not store AbsolutePath in CellTag. Better store the folderitem itself.
Why is that Christian?
because you should avoid string operations on paths and better use the methods in folderitem like .parent or .child.
You avoid trouble. Because later you will want to get back a folderitem from path and get into tons of errors.
Also the AbsolutePath may be ambiguous while a FolderItem is not. And you need a FolderItem for nearly everything file-related in Xojo so it makes sense to store it directly otherwise you would have to recreate it from the path before you could do anything with the file. Pretty much the only uses for a path are for presenting it to the user or for passing it to some shell script or declare requiring a path.
Advice noted on storing the folderitem itself instead of the absolutepath. My confusion still remains as to why storing the absolutepath worked, but the nativepath did not when attempting to rebuild a folderitem from the path.
While I agree with the sentiment of keeping things in a FolderItem, it’s worth noting that that NativePath is unambiguous.
How were you trying to rebuild the FolderItem?
a lot of people forget the second parameter for GetFolderItem() and get into trouble.
it’s often better to keep the folder items around.
Storing…
//use cellTag(row, 0) to store path to the file
CellTag(LastIndex, 0) = f.AbsolutePath
Recovering…
di[code]m Item as FolderItem
for i As uint16 = 0 to FileList.ListCount - 1
Item = GetFolderItem(FileList.CellTag(i, 0))
//item.Exists = True
//item.exists = False if above code = CellTag(LastIndex, 0) = f.NativePath[/code]as expected: GetFolderitem misses the second parameter…
better:
Storing…
//use cellTag(row, 0) to store path to the file
CellTag(LastIndex, 0) = f
Recovering…
for i As Integer = 0 to FileList.ListCount - 1
dim Item as FolderItem = FileList.CellTag(i, 0)
Also better use integer instead of an uint16.
Bingo!
Thanks for the advice all. I will use Christian’s code instead.
The only problem with storing the folderitem is if the file is on a network drive (not tried other ejectable media) and the drive is disconnected. When you later try to access certain properties you either get nothing back or even worse, your app hangs.
Getting the folderitem from an absolute path is slower and can be ambiguous on a Mac but it does help prevent this problem.
[quote=119705:@Kevin Gale]The only problem with storing the folderitem is if the file is on a network drive (not tried other ejectable media) and the drive is disconnected. When you later try to access certain properties you either get nothing back or even worse, your app hangs.
Getting the folderitem from an absolute path is slower and can be ambiguous on a Mac but it does help prevent this problem.[/quote]
You can always get back to the path and avoid the error with
Folderitem = GetFolderItem(StoredFolderItem.NativePath, PathTypeNative)By storing the FolderItem and generating the NativePath from it, you avoid all ambiguity. I put NativePath here as AbsolutePath is deprecated and chances are it is going to break upon future releases. Therefore AbsolutePath is unadvisable.
I actually mis-quoted the problem I discovered. If you have a FolderItem which refers to a file on a network drive and the network drive is disconnected and then re-connected, accessing the NativePath (or AbsolutePath) causes the application to hang (FB 34112). The only reliable way is to store the path as a string and convert it back when required at the cost of a performance hit.
I agree that NativePath is the way forward but AbsolutePath should be kept around for compatibility. For example, we needed a way to store the path to external files within our documents and the only way we found that allowed the paths to be generated and saved reliably on one operating system and then later read and manipulated on another operating system (Mac > Win32 vice versa) was to store the AbsolutePath. Not the most elegant of solutions but all other ideas we came up with at the time had more problems.
You could always split the NativePath by the platform delimiter and rebuild it each time using FolderItem.Child. That way if one of the pieces doesnt exist you may not get that long delay while it tries to resolve.
I can remember the time in the RB>RS>Xojo world when folderitem.getSaveInfo was the recommended way to store and recover the path to a file. This is now the 2nd extensive discussion of this topic with no mention of that method. There is no deprecation mentioned in the LR. Is this still the recommended way to store a path to a file or DB or not?
[quote=119767:@Kevin Gale]I actually mis-quoted the problem I discovered. If you have a FolderItem which refers to a file on a network drive and the network drive is disconnected and then re-connected, accessing the NativePath (or AbsolutePath) causes the application to hang (FB 34112). The only reliable way is to store the path as a string and convert it back when required at the cost of a performance hit.
I agree that NativePath is the way forward but AbsolutePath should be kept around for compatibility. For example, we needed a way to store the path to external files within our documents and the only way we found that allowed the paths to be generated and saved reliably on one operating system and then later read and manipulated on another operating system (Mac > Win32 vice versa) was to store the AbsolutePath. Not the most elegant of solutions but all other ideas we came up with at the time had more problems.[/quote]
Actually, the only perfectly cross platform solution is the FolderItem, not the AbsolutePath which is only one of its properties.