Jun 01 Tech Review
Volume Number: 17 (2001)
Issue Number: 06
Column Tag: Tech Review
Learning AppleScript the TecSoft Way
by Ben Baumer
Longtime Apple trainer Jerry Neilsen learns me some AppleScript
‘If it's possible for a someone wearing jeans and a bright red T-shirt emblazoned with the Pizza Factory logo to feel like a big shot, it might have been me during the "Workflow Automation with AppleScript" seminar hosted by TecSoft in Santa Monica last month. Not only did Apple validate my parking, saving me a cool 18 beans, but we're talking valet. The instructor of the course, Jerry Neilsen, was a likable, walrus-sized, bearded man with a loud and deep voice. He seemed like someone who could spend his Saturday nights regaling Telemachus with Trojan War stories. Jerry has a natural knack for teaching that has been cultivated by years in the public school system, and it was a pleasure to learn AppleScript from him.
Our Introduction to AppleScript
After we were all assembled in the classroom, we ran through the introductions. The first thing that struck me about the group was the diversity of experience that we had all had on the Mac. There were graphic designers, production editors, de facto office techies, somebody who worked for NASA, and me…the smart-ass Net Admin. I was blown away by how different all of our jobs seemed to be, yet for the most part we were all using the same apps (FileMaker, Quark, Cumulus, BBEdit). Many of us had never had any previous formal training, but had simply put ourselves into positions to help others through independent learning. If there was one thing that united us, that was it. Furthermore, we were all there to take the next step in mastering our Macs, to tackle that nebulous AppleScript thing that we had heard so much about but never fully explored.
Interestingly, everyone in the room claimed to have already written at least one original AppleScript. This was a stretch for me, and I thought for a moment that I would be the group's resident neophyte. However, I was the only student who had any significant programming experience, and this turned out to be much more helpful in learning AppleScript. As we all quickly found out, AppleScript is a lot more like C++ or Java than it is like FileMaker's scripting language or Microsoft Office's Visual Basic for Applications. Jerry hammered home the point that while application-specific macro and scripting languages can operate only within the bounds of their application, AppleScript is capable of bridging applications and transferring data across. However, with this powerful ability comes increased complexity of code.
It's my bet that if you have had experience programming in high-level languages like C++ or Java, you will likely find AppleScript to be incredibly intuitive and easy. In keeping with the Macintosh credo of user-friendly interfaces, AppleScript reads like plain English. Even if you are completely unfamiliar with AppleScript syntax, you might be able to get away with just typing in what you want to happen! The following line was in one of our more advanced AppleScripts:
set fileList to (every file whose file type is "GIFf")
where fileList is an untyped variable. Simple, right? Weakly typed variables help to make AppleScript more accessible and less cumbersome for inexperienced programmers. Jerry likes to argue that AppleScript is not just a scripting language, but a legitimate programming language. I don't know if I agree with him on that, but his point that AppleScript is much more powerful and complex than a macro language, while still less powerful and complex than a full-scale programming language, is well taken.
The Seminar Day-to-Day
We spent most of the first day and a half in a lecture-type classroom, going through the TecSoft Persuasion slide show. While I enjoyed Jerry's enthusiasm and found the presentation thorough, this part moved a little too slowly for me. If you have already learned programming, the concepts of if statements, repeat loops, and subroutines are simply old hat. All I really needed was a quick peek at the syntax and an answer to one or two questions like, "How do you declare local variables?" or "Does AppleScript include a case statement?"
Day two was a nice blend of lecturing and hands-on scripting. I'm a big believer in learning to program with a keyboard and monitor in front of you, so I thirsted for the chance to actually write something in AppleScript. Jerry helped us to customize Apple's ScriptEditor to automatically color-code our code, which seemed a little silly to me at the time, but has since proven invaluable. Before I knew it we were writing scripts that culled information from FileMaker databases or simple text files and placed it neatly in Quark documents. As soon as it became apparent how efficiently and easily AppleScript can move data between applications and documents, my thoughts turned immediately to my own job and where I would be able to use AppleScript to save time and stave off carpal tunnel syndrome. I could almost feel the MacTech CD-ROM creation process getting simpler and more automated!
The third and final day was by far the best. After a short morning lecture we broke into groups and settled into a longer project that we will explore in detail below. This is where Jerry's experience as a teacher really came through for me. Like a scruffy puppeteer he had orchestrated a situation that would result in maximal absorption of the material. I usually find planning programs out on paper to be too tedious and inconsequential for my MTV-addled brain, but in this case it did really help. I am a terrible group worker with an essentially binary attitude: either I'm calling the shots or I'm off in the corner staring at the girls in the cafeteria and dreaming about dunking on my Dad. But this was a productive group experience that was beneficial to us all; we all understood the project much better when it was over.
Our Master AppleScript
The best way to explain what we learned in the seminar might be to step through the code of our master group project and look at what's happening. The goal of this AppleScript is very general, and quite applicable to problems that most beginning scripters will want to use AppleScript to solve. The idea for this script is to drop text from a FileMaker database and images from a Cumulus database into a Quark template. Our code can be broken into three main tell blocks, each of which deals with a single application. This method of isolating applications in tell blocks is certainly not the only way write this AppleScript, but as it turns out, it is the fastest way. I think that it is also more instructive, since you only need to worry about one application at a time.
In this first tell block, we move down FileMaker's object hierarchy to isolate the data we want. In this example, we are only interested in records that are part of the "Z3" series. Accordingly, we use the show statement to show only those records, and then use another tell block to lock ourselves into that subset of data. This step eliminates the possibility of accessing data that is not in the "Z3" series.
tell application "FileMaker Pro 5.0"
tell document "BMW Text Database"
show (every record whose cell "Series" is "Z3")
tell document 1
set imageName to field "Image Name"
— returns a list
set textDesc to field "Text Description"
— returns a list
end tell
end tell
end tell
Now, we can exploit a trick in FileMaker's AppleScript dictionary to store the data from all records in the found set into two variables (imageName and textDesc). The variables will be of data type ‘list.' Using the keyword "field" instead of "cell" returns a list of the data in all records, rather than just the data in one record. This enables us to grab all the information we need from FileMaker without using a time-consuming loop. I thought that this was a neat and compact way to store the data we wanted from FileMaker. The items in these two lists correspond with one another (i.e. - the first item in imageName comes from the same FileMaker record as the first item in textDesc).
The next step in our script was to pull the paths to images stored in a Cumulus database. Cumulus, from Canto Software, is a top-flight media asset management tool for both Mac OS and Windows. The Cumulus "collection" in question acts as a central storage place for the multimedia files needed to complete this project. Again, we used a tell block to cordon off our Cumulus work, and a list to store the paths to the images.
tell application "Cumulus S5.0"
tell collection "BMW Image Database"
set imagePath to {}
— defines imagePath as an empty list
set listlength to 0
repeat with x in imageName
set listlength to listlength + 1
set nextImage to (asset of every record whose name = x as string)
set imagePath to imagePath & nextImage
— adds nextImage to the list imagePath
end repeat
end tell
end tell
In this repeat loop, we step through the list of image names that we got from FileMaker (counting the number of items at the same time) and match them with corresponding records in the Cumulus collection. The "asset" of each matched record is the full path to the image, which we will need when we want to import these image files into Quark.
At this point we have all the information we need stored in three lists of equal length: imageName, imagePath, and textDesc. We also have the number of total records stored in the variable listlength. All we have to do is step through each list and drop the corresponding items into their appropriate places in our pre-formatted Quark template. Again, we used a tell block to talk exclusively to Quark.
tell application "QuarkXPress™"
activate
set counter to 0
— creates a variable that will help us keep track of which list item we are accessing
repeat listlength times
set counter to counter + 1
import file (item counter of imagePath) to picture box counter of spread 1 of document 1
set bounds of image 1 of picture box counter of spread 1 of document 1 to proportional fit
make new text at beginning of story 1 of text box counter of spread 1 of document 1 ¬
with properties {contents:item counter of textDesc, size:12}
end repeat
end tell
The counter variable helps us match up the corresponding list items and identify where we are in the list. The import file statement drops the appropriate image into the appropriate picture box using the path of the image file (from Cumulus). We then resize the image proportionally to fit the box. Next, we drop the corresponding text description (from FileMaker) of the image into the appropriate text box, and set the style of the text. This process repeats for each item in the list, and we're done.
What I liked about this assignment was the general applicability of the tasks that were performed. If you ever use FileMaker, Cumulus, or Quark, chances are high that you are going to be repetitively importing and exporting data from them. Since all of these applications are exceptionally scriptable, it is a good bet that you can use AppleScript to do some of this work for you. I felt like this was a perfect example of how to make AppleScript work for you, and I had never even heard of Cumulus before this seminar.
Conclusion
This seminar is by no means limited to those who work in the technology sector. In fact, the common characteristic that my classmates and I shared was not our profession or level of technical expertise, but the applications we used on a daily basis and a proclivity towards learning new things on the Macintosh. If you are using scriptable applications like those mentioned in this article (be sure to include the Finder as well!) to do even mildly repetitive tasks, then you are a prime candidate to benefit from learning AppleScript. Both you and your company will see rewards, both immediate and in the long run. TecSoft's seminars can set you off and running in this direction.
Part of me wants to argue that TecSoft should offer separate classes for those with programming experience and those without, but I can see that that reflects only my own experience with the seminar and ignores that of the majority. Despite my occasional boredom, the seminar was extremely effective in accomplishing its main goal: teaching us how to use AppleScript to make our jobs easier. If you've already learned a high-level programming language, you can probably get away with reading a book and practicing on your own, but I feel incredibly fortunate to have had access to a teacher like Jerry Neilsen. I appreciated getting the broad overview of AppleScript without having to read a book, and having a knowledgeable instructor there to answer questions saved me some inevitable frustration. Jerry impressed upon us vigilantly the importance of learning how to use an application's dictionary on our own to find out how the program can be controlled by AppleScript. Since AppleScript is inherently dependent on third-party applications, this skill is not extra-credit, but par for the course. I definitely felt that by the end of the class, there were three things that Jerry had imparted to us that would allow me to learn all I ever wanted to know about AppleScript through practice and investigation:
A fundamental understanding of applications' object hierarchies
How to open, read, and understand an application's AppleScript dictionary
How to use the AppleScript Help menu to flesh out syntactical problems.
Simply put, the TecSoft course met its objectives. After having completed the course, I was able to write AppleScripts that enabled me to do my job more efficiently through the use of "Workflow Automation." I have Jerry Neilsen and TecSoft to thank for that, and as such, I give the seminar high marks.
References
Ben Baumer (
netadmin@xplain.com) is the Network Administrator for the Xplain Corporation. He is hoping that this article will create such a firestorm that he will be able to launch a writing career and dominate the Best American Short Stories series for years to come.
