Chapter 9: continued

A Closer Look

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 Finder 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. Note that it is written using the "on" form to define a handler; this name must match the name of its temporary location in the system.deskscripts table. When you double-click on a desktop script, Frontier gets its file path and passes that as the value of the "path" parameter. This feature lets the desktop script operate on the folder that contains it. In fact, you could have many copies of a desktop script, each in a different folder.

Since a UserTalk script is a form of a Frontier outline and since the Frontier outline uses solid black item markers to indicate a collapsed heading, you have probably concluded that this script has some collapsed lines. You're right. Using the outline approach to scripting permits you to show the user only as much of a script as you want them to see or as much as you think they'd be interested in. Here, the script is collapsed enough so that you get an idea of the overall structure of the script. The second line of the script initializes a variable to hold the number of Word files the script locates. Next, there is a local script called "counter" embedded in the countWordFiles script. (You can tell it's the definition of a script because it starts with the word "on.") We'll get to that in a moment. Next, we call the local script named counter and pass it the name of the folder in which it is stored (which we find out by using the Frontier verb file.folderFromPath). At the end of the script -- in other words, after counter has run its course -- we see if any files were found and take some action accordingly. As you can see, Frontier gives you the ability to take a very top-level view of a script.

Now let's "drill down" one level deeper into this structure and look at the local script called counter. Here is the full script as we've seen it so far, with that local script open two levels deeper than it was in our last look.

Again, we can see that there are collapsed lines in this local script as well, but we can get a pretty good idea what's going on by looking at the portion that is expanded. The first line in the local script called counter sets up a looping construct of some sort. The fileloop construct (described in Chapter 4 and in DocServer) is unique to UserTalk. It sets up a loop that will go through every file and folder within the listed folder. The next two lines tell us that the routine does one thing if the object it finds is a folder and another thing if it's a file (the only other possibility). Let's take a deeper look at what happens if the object is a folder.

This time we've only shown you the part of the script on which we are focused. There is only one line under the line that tests to see if the object is a folder. It in turn calls the counter local script to iterate over this new-found folder. This is an example of the computer programming concept known as "recursion." A routine is said to be recursive if one or more lines of code within the routine calls the routine itself. This line simply stops when it gets to a folder and tells the counter script to execute on all of the files and (potentially) nested folders in this newfound folder.

What if the object is a file and not a folder? Here's the next level of counter expanded so you can see the next round of detail.

If the else portion of the script is executed (which means that we know we're looking at a file and not a folder), the name of the file is displayed in Frontier's Main Window as a kind of progress report. Then the script does another check to see if the file is a Microsoft Word file. It does this by checking the file's creator type, a "string4" value that uniquely identifies the application that created the file. (Note that the file.creator verb gets the creator from the file, returning it to the "if" statement to compare to 'MSWD'. Frontier accepts either "==" or "equals" for the comparison operator.)

Here's the full counter script:

If the file is a Microsoft Word file, we use the increment operator (++) to add 1 to the variable called matchesFound.

This looping process continues until all of the files and folders in the folder from which the desktop script was launched have been examined. Let's look at the last part of the script.

If the variable matchesFound has a value of zero, then we want to tell the user there weren't any Word files in the folder. If there is at least one Word file in the folder, however, we want to tell the user how many we found.

The else part simply displays a dialog box with the number of Microsoft Word files it found. Note that the message is somewhat long, so it was built in two steps as a local variable. Why does the original definition of "s" call both fileFromPath and folderFromPath? The inner function returns the entire path to the folder, starting from the hard disk. The outer function takes just the "file" -- i.e. the name of a file or folder without the full path. If you like to eliminate every bit of redundant code, you could create another local script called something like parentFromPath that encapsulated both of these verbs.

Here is the script for "Count Word Files," fully expanded to show you every line:

Now you see what a typical UserTalk script looks like and you have some idea how a desktop script works. We won't go into such detail on the remaining desktop scripts we discuss in this chapter.