I’ve been fooling around with this today out of interest. The observations here are musings rather than actual recommendations.
If you use ‘run script’ to run a script directly from the file, the script can save any property changes it makes itself by resaving itself after the changes:
property MyMessage : missing value
if MyMessage is missing value then
display dialog "Create message" default answer ""
set MyMessage to text returned of result
store script me in (path to me) replacing yes -- Get the script to resave itself.
end if
display dialog MyMessage
BUT this is a dangerous thing to do because you might one day forgetfully use it in a script for loading. In this case, ‘path to me’ would refer to the file of the main script and the loaded script would save itself there ” with obvious consequences for the main script.
A safer approach, as Shane suggested, would be to store the property values separately. For instance, the auxiliary script could itself be a bundle and contain a file or files containing the required values. In the following example, the script’s a bundle whose resource folder also contains a “Properties” folder and therein an empty file called “MyMessage.txt”.
set messageFile to (path to resource "MyMessage.txt" in directory "Properties")
if ((get eof messageFile) > 0) then
set MyMessage to (read messageFile as «class utf8»)
else
display dialog "Create message" default answer ""
set MyMessage to text returned of result
set fref to (open for access messageFile with write permission)
try
write MyMessage as «class utf8» to fref
on error msg
display dialog msg buttons {"OK"}
end try
close access fref
end if
display dialog MyMessage
This likewise only works when ‘run script’ is applied directly to the script file. If the script’s loaded into another script before running, it’ll error harmlessly unless the parent script has a similar resource of its own. And if the main script should happen to have a resource with the same name in a similar location, the worst that can happen is that the wrong resource will be overwritten. The main script itself won’t be.
A further step would be to require the subsidiary script to take a parameter. This would be used to pass its own alias to it, allowing it to work correctly either from the file or after loading into another script and making it harder to use wrongly. It wouldn’t prevent a determined bonehead from passing it the wrong alias, but if it was for your own use, it might serve the turn.
on run argv
if ((argv's class is list) and ((count argv) is 1) and (class of item 1 of argv is alias)) then
set myPath to item 1 of argv
set messageFile to (path to resource "MyMessage.txt" in directory "Properties" in bundle myPath)
if ((get eof messageFile) > 0) then
set MyMessage to (read messageFile as «class utf8»)
else
display dialog "Create message" default answer ""
set MyMessage to text returned of result
set fref to (open for access messageFile with write permission)
try
write MyMessage as «class utf8» to fref
on error msg
display dialog msg buttons {"OK"}
end try
close access fref
end if
display dialog MyMessage
else
display alert "InternalScript 3 invoked with wrong syntax." message "Use:
run script <alias or script> with parameters {<the script's file alias>}" as critical buttons {"Stop"} default button 1 cancel button 1
end if
end run
It might be invoked from the main script thus:
set MyInternalScriptFile to (path to resource "Scripts/TestInternalScript 3.scptd") -- Substitute the relevant script name.
run script MyInternalScriptFile with parameters {MyInternalScriptFile}
Or:
set MyInternalScriptFile to (path to resource "Scripts/TestInternalScript 3.scptd") -- Substitute the relevant script name.
set MyInternalScript to (load script MyInternalScriptFile)
run script MyInternalScript with parameters {MyInternalScriptFile}