What I am trying to do is create an applescript app that can take a list of files (well generally a single file) and save the file paths to a text file. So a user will double-click a file associated with my app which will then get the path to the double-clicked file and save it to a text file and then launch a director app which will check the text file to see if any files were double clicked.
I have this so far which creates the text file but doesn’t write anything in it? Is this the right usage of the open handler?
on open theFiles
writeIni(theFiles)
end open
on writeIni(theFiles)
set theFiles to (theFiles as list)
set theText to ""
repeat with theFile in theFiles
set thePath to (theFile as string)
set theText to (theText & thePath & return)
end repeat
tell application "Finder"
try
set theTextFile to (container of application file (path to me) as string) & "Launch.ini"
open for access theTextFile
write theText to theTextFile
close access theTextFile
on error
end try
end tell
end writeIni
Your open handler’s fine (assuming you’re writing a droplet). You need to open the text file ‘with write permission’ before you can write to it. If you want to overwrite any data that may be in the file, set the ‘eof’ (end-of-file marker) to 0 first. If instead you want to append your text to the end of the data, write it ‘starting at eof’.
on open theFiles
writeIni(theFiles)
end open
on writeIni(theFiles)
set theFiles to (theFiles as list)
set theText to ""
repeat with theFile in theFiles
set thePath to (theFile as string)
set theText to (theText & thePath & return)
end repeat
tell application "Finder"
try
set theTextFile to (container of application file (path to me) as string) & "Launch.ini"
set fRef to (open for access file theTextFile with write permission)
-- Uncomment whichever expression you want to use.
try
-- set eof fRef to 0
write theText to fRef -- starting at eof
end try
close access fRef
on error
end try
end tell
end writeIni
By the way, the current received wisdom, when coercing file specifiers to text, is to use ‘as Unicode text’ rather than ‘as string’. But both work on English-language systems, of course.
