Chapter 9: Desktop Scripts

Desktop scripts are a convenient way to make the power of Frontier available right on your desktop. In this chapter, we'll take a quick look at some of the desktop scripts that are packaged with Frontier. Then we'll examine two of these scripts closely so that you can see how they work. Next, we'll discuss how you can customize desktop scripts. Finally, we'll explain how to create a desktop script from scratch.

Our focus here is to give you an overview of desktop scripts, it's not critical that you understand the details of every script. Remember, to get details on any verb, look it up in DocServer.

An Overview of Desktop Scripts

Frontier comes with a number of useful desktop scripts. They are stored in a folder called "Desktop Scripts" in the Frontier distribution package. Like all good Macintosh applications and goodies, their names tell you a lot about their purpose. For example, the Frontier desktop script called "Find in File" looks through the contents of a file for a string. "Folder Structure" creates an outline representing the folder or volume in which it is stored. You get the idea.

These scripts appear to the user much like stand-alone Macintosh applications. However, they require Frontier to be available, making them a cross between a document and an application.

If you double-click a desktop script in the Finder -- or even open one from Frontier's File menu -- the script will run. So, how do you edit it? There's a trick: when you double-click on the file, hold down the Command key and continue holding it until the script is open in Frontier. (If you let go before the Mac OS passes control to Frontier, Frontier will just run the script since it has no way of knowing that you held the key down briefly.)

Two examples

In this section, we will take a close look at two of the desktop scripts that come with Frontier. For each, we'll examine its purpose and then review the script.

Desktop scripts often loop through all files in a folder (or nested set of folders) and extract information or make changes using Frontier's extensive set of file and system verbs. Here are two examples:

• Count Word Files
• Recently Changed Files

Count Word Files

This desktop script goes through a folders and all its sub-folders and counts the number of files created by Microsoft Word. It then displays the result.

Here is the script for Count Word Files, as it appears when you open it in Frontier the first time.

Figure 9-1. Count Word Files desktop script.

Like all desktop scripts, this script finds out what file it was launched from thru the global variable, system.deskscripts.path. It uses the built-in file.folderFromPath verb to pop out one level, so it can loop over all the files in the folder that contains it. This means you can move the script to a different folder to get it to count the Word files in that folder.

The count of Word files is initialized to 0, and then the script sets up a loop that goes thru all the files contained in the folder, to infinite depth. When it encounters a file whose creator ID is 'MSWD', it adds one to the counter.

When the loop is complete, a message is created, saying how many matching files it found. With UserTalk's case statement, it produces a syntactically correct English statement. and displays it using Frontier's built-in dialog.notify verb.

Recently Changed Files

The next desktop script we'll look at is called "Recently Changed Files." As its comment informs us, it creates a folder and then places into that folder aliases of files that have changed since a user-selected date.

Here is what the script looks like in one view, where we've collapsed some of its lines for easier reading:

Figure 9-2. Recently Changed Files desktop script

We first set up a date -- here it's October 1, 1991 but you could obviously change it -- and then we use that as the default answer as we ask the user to define which files are to be gathered. We make sure that this value is a date by converting it with the date verb.

The next two sets of lines define local scripts called recentlyChanged and doGather. We'll come back to them shortly when they are called from the main script.

Before we start gathering aliases of all the recently changed files, we create a new folder called "Recently Changed Files", inside the folder from which the script is run. If a folder of this name already exists, we delete it before creating a new one. Note the "if not" technique to trap the rare case that file.newFolder returns false to indicate that it failed to create a new folder. (Perhaps the desktop script is on a CD or other locked volume.) It's a good habit to anticipate errors and design your code to handle them.

Now the script initializes a variable called ctgathered (the "ct" is a mnemonic for "count") to zero and then calls the local script doGather with the name of the folder in which it is running as an argument. Let's examine the doGather local script.

After defining a local variable, the script loops over all the files in the path. It then takes different actions depending on whether the "file" is a folder or a file, much as we saw with the CountWordFiles script in the last section. Let's open those two sets of lines; the doGather script now looks like this:

As you can see, if doGather encounters a folder, it first checks to make sure this isn't the folder we're in the process of creating (or the result could get very messy!) and then calls itself recursively, just as we saw with CountWordFiles. If the item it encountered is a file, the script displays the name of the file in Frontier's Main Window as a progress indicator, then calls the recentlyChanged local script. That simple script looks like this:

This script consists of one executable line that compares the date the file was last modified against the date the user has indicated we should use as a base date for gathering files. If the file's date of last modification is later than the date the user provided, this routine will return an answer of "true" to doGather. Otherwise, it returns false.

Now you can go back to doGather and see that it checks the return value from recentlyChanged. If the value is true, it creates a new alias for the file, places the alias into the destination folder we're building and then increments by 1 the counter that keeps track of how many files we gather.

When all of the files and folders have been examined, the script looks at the value of the variable ctgathered.

If at least one file has been found, it opens the folder so the user can see the results of gathering all of these aliases. Otherwise, it deletes the folder and informs the user that it couldn't find any files to gather.

Customizing the scripts

The desktop scripts that come with Frontier are useful as is, but we obviously couldn't anticipate all the tasks you might want to automate. Since they're scripts, you can change them to fit your needs. We'll look at two possible changes to these scripts here; realize that these examples are simply designed to get your creative juices flowing about things you might do with these desktop scripts.

Counting other kinds of files

The most obvious way you could customize the first example, countWordFiles, would be to look for files other than Microsoft Word files. You can do so by opening the script in Frontier (while holding the Command key) and making these simple changes:

• Rename both the "on" handler and the cell in the Object Database where the script lives.

• Replace "Microsoft Word" in the comment on line 2 with the name of the application whose files you want to find.

• Change 'MSWD' to the four-letter creator code of the application whose documents you wish to find.

• In the last part of the script, change "Word" to the name of the product whose document files you are counting.

If you want to get really ambitious, you could write a script that would prompt the user with the standard file dialog box, get that application's four-character creator type, and then use the result to count the files. These tasks, as authors of the college textbooks say, are exercises left to the reader.

Using a folder's date as a starting point

Our second example, the "Recently Changed Files" script, has the default date entered directly as a value. Programmers call this "hard coding" information and it's generally not a good idea. One solution is to have the script suggest a date based on the current date, perhaps one week earlier. Change the line that now reads:

s = "October 1, 1991"

to

s = clock.now () - (7 * 24 * 60 * 60)

This statement subtracts from the present day and time the value of seven days times 24 hours per day times 60 minutes per hour times 60 seconds per minute. It produces a time exactly 168 hours before the present time.

You could use other approaches to the problem of the hard-coded date. For example, you could check to see if the folder called "Recently Changed Files" exists and, if it does, use the file.modified verb to get its modified date. This approach lets you gather only files that have changed since the last time you gathered changed files.

Creating Desktop Scripts

Most desktop scripts deal with operations that make sense at the Finder level, involving things like files, folders, and system issues. But that is not necessary. Any UserTalk script that you'd like a user to be able to launch by double-clicking it in the Finder can be made into a desktop script.

To create a new desktop script, choose the New Script command from Frontier's Main menu. Choose Desktop script from the Kind popup and enter the name of the script in the text entry box. Click on OK.

Figure 9-3. Frontier 4.1's New Script dialog

The new script is placed in system.deskscripts table. This is the default (and safest) place to store desktop scripts. Here's what the script looks like:

Figure 9-4. Script editing window showing newly created script

Note that in the new scheme for desktop scripts, there's no need to supply an "on" header. The path to the script is stored in a global in the object database, at system.deskscripts.path. From that, we can compute the folder, and since we know that almost all desktop scripts need to do this, we programmed Frontier to insert the code for you automatically.

Quickly, I added code that sums the sizes of all files contained in the same folder as the script and displays the result in a dialog box:

Figure 9-5. Script editing window containing completed script

It's often a good idea to test the desktop script at this point, by running it in the script debugger. Once you're ready to try it out for real, you need to export it to the desktop. To do so, first be sure that the script you want to export is open and frontmost, then choose Export from Frontier's Main menu. A dialog appears:

Figure 9-6. Export dialog set up to export a desktop script

Be sure that the Kind popup is Desktop script and that the location popup is File and that compression is None. These should be the defaults. Click on OK to export the script. A standard file dialog appears allowing you to specify the name and location of the file that contains the script.

Before you give a desktop script to another user to work with, we recommend that you test it on at least one system other than your own to check for errors such as including a reference to a specific hard disk.

One final tip. If the window for the folder or volume to which you export the desktop script is open when you export the script, you may have to close the folder and then re-open it for the desktop script to be able to be launched with a double-click. This limitation is one of the quirks of the System 7 Finder.

---

© Copyright 1996-97 UserLand Software. This page was last built on 5/7/97; 1:10:16 PM. It was originally posted on 9/24/96; 9:43:23 AM. Internet service provided by Conxion.