• Choose a category
• All
• Classic-Fiction

However, if you open this script with Script Editor, the script is ruined, because Script Editor strips out the saved top-level entities when it opens a file. Furthermore, if you edit this script on another machine, the script is ruined. At that point, the values of the script properties will be thrown away, AppleScript will try to reinitialize them, the load script command will fail because the file it refers to doesn't exist, and the script will no longer compile or run. Thus, this trick is probably most appropriate when you can afford to distribute a script as run-only.

(Actually, Script Debugger helps you further in this situation as well. It lets you "flatten" a script so that it incorporates all library files on which it depends, and so has no load script dependencies.)

An interesting attempt to rationalize the library mechanism is the freeware utility Loader . The idea is to try to make it as easy to install and take advantage of libraries, even if they involve mutual dependencies, as in languages like Perl and Python. I haven't tried this myself, but it looks intriguing.

Name

load script

Syntax

load script aliasOrFile

Description

Returns the top-level script of the compiled script file or applet aliasOrFile as a script object.

Example

set myScript to load script alias "myDisk:myFile.scpt"

Name

run script

Syntax

run script aliasOrFile [with parameters list]

Description

Tells the top-level script of the compiled script file, applet, or text file aliasOrFile to run (compiling first if necessary), optionally handing it the list as the parameters for its explicit run handler, and returns the result.

Example

run script alias "myDisk:myFile.scpt"

Name

store script

Syntax

store script scriptObject [in aliasOrFile [replacing yes|no]]

Description

Saves scriptObject to disk as a compiled script file or applet. Returns no value. If no further parameters are supplied, presents a Save File dialog; if the user cancels, a runtime error is raised. If aliasOrFile is supplied, the Save File dialog is suppressed, but if the file exists already, presents a dialog asking how to proceed; if the user cancels, a runtime error is raised. If replacing is supplied, this dialog is suppressed; if yes, the file is just saved, and if no, an error is raised if the file exists. The filename extension determines the format of the resulting file: .scpt (or nothing) for a compiled script file, .scptd for a script bundle, .app for an applet. (The applet will be an applet bundle unless a nonbundle applet already exists.)

Example

store script sayHello in file "myDisk:myFile.scpt" replacing yes

Inheritance

Script objects may be linked into a chain of inheritance . One script object inherits from another if the second script is the parent of the first. Then, suppose an attempt is made to access a top-level entity of the first script object (using the special syntax described in "Accessing Top-Level Entities," earlier in this chapter). If the script object has no such top-level entity, the attempt is passed along to its parent to see whether it has such a top-level entity.

It turns out that every script object has a parent property. This property is set for you if you don't set it (and so there is always an inheritance chain, even though you might not be aware of this). To link two script objects explicitly into a chain of inheritance, initialize the parent property of one to point to the other.

Tip

The parent property may be set only through initialization (that is, through a script property declaration). You cannot use copy or set to set it.

In this example, we explicitly arrange two script objects, mommy and baby, into an inheritance chain (by initializing baby's parent property). We can then tell baby to execute a handler that it doesn't have, but which mommy does have. Here we go:

script mommy

on talk( )

display dialog "How do you do?"

end talk

end script

script baby

property parent : mommy

end script

baby's talk( ) -- How do