AppleScript_ The Definitive Guide - Matt Neuburg [70]
Similarly, when a script object is defined within a handler, it has no persistence. The script object is created anew each time the handler runs. This is true even in a script object's explicit run handler. This code illustrates that a script object in an explicit run handler does not have persistent top-level entities:
script myScript
on run
script myInnerScript
property x : 10
end script
tell myInnerScript
set its x to (its x) + 1
display dialog its x
end tell
end run
end script
run myScript -- 11
That code yields 11 every time it runs. As I said in "Code and the Run Handler" in Chapter 6, only stuff in the implicit run handler is at the top level. An explicit run handler is an ordinary handler, and stuff inside it follows the rules for being inside a handler. So myInnerScript is not defined at the top level of a script object; it is not a top-level entity, and has no persistence.
File-level persistence
So far we've talked about persistence only while a script window remains open for editing in a script editor application. But what about when a script is saved as a compiled script file and its window is closed? Does persistence work when the script file is opened for editing again later? And does persistence work when a saved compiled script file is repeatedly executed by a script runner?
The answer, unfortunately, is: it depends. Persistence doesn't work if you save, close, and open a script file using the current Script Editor. When you run the newly opened script, you find that everything is reinitialized. On the other hand, such persistence does work with older versions of the Script Editor (1.9 or before), or with Script Debugger. Create and run this script several times in Script Debugger:
property x : 5
set x to x + 1
display dialog x
Now save the script as a compiled script file, and quit, just to prove to yourself that AppleScript's own memory of the value of x is well and truly erased. Now open the compiled script file again (in Script Debugger) and execute it. The incrementing of x picks up right where it left off previously.
It would be really nice if persistence always worked in a compiled script file, but unfortunately this mechanism is not automatic, and in fact has nothing to do with AppleScript itself. AppleScript has no way to enforce file-level persistence, because AppleScript doesn't deal with files. It is up to the environment that's talking to the AppleScript scripting component, after it asks AppleScript to run a compiled script file, to save AppleScript's copy of the compiled script back into the compiled script file after execution. If it doesn't do this, then the compiled script file won't contain the new values, and the values won't persist. Script Editor and Script Debugger behave differently in this regard.
Similarly, script runners and other environments that execute compiled script files can behave differently. Some environments do save the compiled script file back to disk after each execution along with any changed top-level entities. For example, applets do this. So does Apple's Script Menu, and so does BBEdit with its Script menu. But Entourage's Script menu, for example, does not.
Actually, persistence in Apple's Script Menu (and perhaps some other environments) is itself inconsistently implemented. It turns out that the Script Menu implements persistence only if execution of the script returns a value (even though this value is otherwise ignored). Some actions, such as the user canceling out of a dialog, can cause the script to return with no value, and in that case, persistence fails. You can guarantee persistence in this situation by trickery, making sure that the script returns a value no matter what. In the case of display dialog you can catch the error produced by the user canceling and return a value anyway:
property x : 5
set x to x + 1
try
display dialog x
on error
return 0
end try
All this inconsistency