• Choose a category
• All
• Classic-Fiction

property total : 0

on open what

repeat with f in what

if folder of (info for f size no) then set total to total + 1

end repeat

display dialog (total as string) & " folder(s)"

end open

On the other hand, this persistence naturally ends as soon as the applet's script is edited. If you're still developing an applet, or are likely to edit it further for any reason, you might like a way to store data persistently with no chance of losing it. The application bundle format supplies a solution. An application bundle looks, and behaves in the Finder, just like an applet , but is in reality a folder. We can perform persistent data storage in a separate file inside the bundle; the user won't see this separate file, and its data will persist even when we edit the applet's main script.

To illustrate, let's return to the example in "Data Storage" in Chapter 8. This code is just the same as in that example, except that we now assume we are an application bundle, and the opening lines have been changed to store the data inside the bundle:

set thePath to (path to resource "applet.icns") as string

set text item delimiters to ":"

set thePath to ((text items 1 thru -2 of thePath) as string) & ":myPrefs.scpt"

script myPrefs

property favoriteColor : ""

end script

try

set myPrefs to load script file thePath

on error

set favoriteColor of myPrefs to text returned of ¬

(display dialog "Favorite Color:" default answer ¬

"" buttons {"OK"} default button "OK")

store script myPrefs in file thePath replacing yes

end try

display dialog "Your favorite color is " & favoriteColor of myPrefs

The first three lines of the script are a rather elaborate song-and-dance to obtain the pathname of the bundle's Resources directory. We could hardcode the path from the top of the bundle, like this:

set thePath to (path to me as string) & "Contents:Resources:myPrefs.scpt"

Instead, we use the path to resource command. But this command has an odd functionality hole: we can obtain the pathname of a resource file inside the Resources directory, but not the pathname of the directory itself. So we start with a resource file we know is present and work our way up the folder hierarchy and back down again.

Applet Scriptability

We have seen already that an applet is scriptable with respect to its event handlers: you can tell an applet to run, open, reopen, idle, or quit, and the corresponding event handler will be called. An applet is scriptable also with respect to user handlers. You call them like ordinary handlers. For example, suppose we have a stay-open applet howdy whose script goes like this:

on sayHowdy(toWhom)

activate

display dialog "Howdy, " & toWhom

end sayHowdy

Then we can say in another script:

tell application "howdy"

sayHowdy("Matt")

end tell

The value is returned as one would expect; here, the calling script receives the value {button returned:"OK"} if user presses the OK button.

The reason this is possible is that AppleScript's mechanism for calling a user handler in a script object is extended to work even when you're talking to an applet . The call is translated into a special event, the Call·subroutine command ('ascr\psbr'). This is a sort of meta-command; its parameters are the name of the handler you're calling and the parameters you're passing. At the other end, the target applet unpacks the handler call and performs it within its script. Thus it's just as if you said sayHowdy("Matt") from inside the applet's script. If the script defines such a handler, the result comes back as the reply. If it doesn't, you get a "Can't continue" error message. (This error message is familiar from when you accidentally use this same mechanism to send a user handler call to an ordinary scriptable application, which, as we have seen in Chapter 11 and elsewhere, is all too easy to do.)

An applet is also scriptable with respect to its other top-level entities. If an applet has a top-level property x, you can get and set its x. And if an applet defines a