> Right, GetSaveInfo isn't a path (in general), but binary data that > probably includes an alias record on MacOS. Which is neat, because it > may continue to resolve even if the user has moved or renamed the > original file. And of course it won't be fooled by having two volumes > mounted with the same name, unlike a path.
What if you move the file away,t hen put a better file in it's place? I do that a lot. I expect the new one to be used. For example, I take a plugin out of my plugins folder, and put a newer version in. OK plugins is a bad example as no paths need to be saved. But this is the case for things like external project items, or in Xcode it would be the case for .cpp files. If we were using relative paths instead of aliases, the update would work correctly. I always fix up my Xcode projects to use relative paths. This means the project works on any computer. No aliases necessary, and if I move files around and put better .cpp files in... Xcode knows the one I want, because it's in the correct place. Relative paths are just more intuitive. Admittedly, Xcode doesn't use relative paths as often as it should. It has a nasty habit of using absolute paths for project .cpp files, whose path could change if I move the project around. That's why I need to alter the filepath settings to relative at first. -- http://elfdata.com/plugin/ "String processing, done right" _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
