Page 1 of 1
Mac relative paths in IDE
Posted: Mon Feb 24, 2014 9:40 pm
by CenturyMan1979
Hey All,
I am updating a program on Mac that was originally created on PC. While I am in the IDE I can't seem to use relative paths to external resources. Here is simple example,
This code does not work from the message box
Code: Select all
put there is a file ("Resources/_Look/Backgrounds/2014_Background_LightGrey.jpg")
But if I give it the full path it works
Code: Select all
put there is a file ("/Users/[USER_NAME]/_Work/[PROJECT_NAME]/src/Resources/_Look/Backgrounds/2014_Background_LightGrey.jpg")
So when my program runs in the IDE images will not import but if I export the application out and run it then the relative paths work just fine. So is there something I need to do to make relative paths work in the IDE?
Re: Mac relative paths in IDE
Posted: Mon Feb 24, 2014 11:27 pm
by Kangaroo SW
@CenturyMan1979
Try:
--•• LiveCode path to compiled executable in App Bundle -> varPosixPathToApplicationBase
put the effective filename of this stack into varPosixPathToApplicationBase
--•• get posix path to resources folder works with stacks and the executable all files in the folder Resources are accessible
set the itemDel to slash
delete last item of varPosixPathToApplicationBase
put convertLiveCodeToUnixPosixPath(varPosixPathToApplicationBase & "/Resources/") into varPosixPathToResources
function convertLiveCodeToUnixPosixPath varLiveCodePath
--•• changes a LiveCode to a POSIX UNIX style path
put "\" & space & quote & "'`<>!;()[]?#$^&*=" into varSpecialChars
repeat for each char varChar in varSpecialChars
replace varChar with ("\" & varChar) in varLiveCodePath
end repeat
return varLiveCodePath
end convertLiveCodeToUnixPosixPath
Cheers
Rolf
Re: Mac relative paths in IDE
Posted: Tue Feb 25, 2014 2:14 pm
by Klaus
@Rolf
Pathnames do not need to be "escaped" for Livecode!
@Centuryman
Use a slightly shorter variation of Rolfs script, presuming [PROJECT_NAME] means your current stack:
Code: Select all
function tResourcePath
put the effective filename of this stack into tPath
set the itemDel to "/"
put "src/Resources/ into item -1 of tPath
return tPath
end tResourcePath
But you can use relative (to the stack) pathnames for images, videos and audio files:
...
set the filename of img "an image object" to "src/Resources/_Look/Backgrounds/2014_Background_LightGrey.jpg"
...
Best
Klaus
Re: Mac relative paths in IDE
Posted: Tue Feb 25, 2014 7:14 pm
by CenturyMan1979
Turns out if I remove my code checking for the file then the images do end up loading in just fine. So it seems relative paths are not working when using "there is a file".
Here is the bit of code that would not work with relative paths, pFile contains a relative path to an image
Code: Select all
if (there is not a file pFile) then
answer "Missing Image File:" && pFile
return empty
end if
Is there any other methods that don't handle relative paths on mac I should be on the lookout for?
I think I will take your code and just make it a general method I can throw any relative path at,
Code: Select all
function absPath pRelativePath
put the effective filename of this stack into tPath
set the itemDel to "/"
put pRelativePath into item -1 of tPath
return tPath
end absPath
Re: Mac relative paths in IDE
Posted: Wed Feb 26, 2014 7:45 am
by jacque
Relative file paths depend on the defaultFolder, which when the IDE launches is set to the folder containing the LiveCode app. The "is a file" syntax works fine with relative paths, but you first need to set the defaultfolder to the one containing your stack. There aren't any problems with any of the file constructs, it's just that in this case the engine is looking in the applications folder for the file.
The reason the function works is because it converts the file path to an absolute one. I use a similar function all the time, but you can also do something like this to get the same result:
Code: Select all
if the environment is "development" then
put the effective filename of this stack into tPath
set the itemDelimiter to slash
set the defaultFolder to item 1 to -2 of tPath
end if
Then you can use relative paths without any conversion.
Re: Mac relative paths in IDE
Posted: Wed Feb 26, 2014 6:22 pm
by CenturyMan1979
Thank you jacque. That is exactly what I needed. The strange part is on PC I did not have relative path issues in the IDE so not sure if this should be reported as a MAC bug.
Re: Mac relative paths in IDE
Posted: Wed Feb 26, 2014 10:42 pm
by FourthWorld
It may not be a bug. Remember that Mac standalones put the executable in a separate folder within the bundle, so unless you move your Resources folder into the one with the executable your path will need to move one level up ("..") before attempting to find the Resources folder.
Re: Mac relative paths in IDE
Posted: Thu Feb 27, 2014 12:41 am
by jacque
It sounds odd to me though, Mac bundles notwithstanding. If you relaunch LiveCode (so it's using its default values) and put this into the message box on PC:
put the defaultFolder
what does it say?
EDIT: If you double-click a stack to launch the IDE, then the folder the stack was in will be the defaultFolder. Maybe that's what happened?
Re: Mac relative paths in IDE
Posted: Mon Mar 03, 2014 5:06 pm
by CenturyMan1979
jacque wrote:It sounds odd to me though, Mac bundles notwithstanding. If you relaunch LiveCode (so it's using its default values) and put this into the message box on PC:
put the defaultFolder
what does it say?
EDIT: If you double-click a stack to launch the IDE, then the folder the stack was in will be the defaultFolder. Maybe that's what happened?
That turned out to be the difference jacque. On pc if you double click the file to be open in livecode on PC then the defaultFolder is set to the location of the file you opened. On mac this does not happen, it keeps the path to livecode either way. This does seem like a bug on the mac/pc as the IDE should behave the same on both platforms.
Re: Mac relative paths in IDE
Posted: Mon Mar 03, 2014 7:34 pm
by jacque
I agree. You might consider posting a bug report on it. The current behavior on Mac has been the default forever so I'm not sure if it's a bug or a feature request, but keeping parity between platforms is always a good idea.