AppleScript

I've been writing AppleScript since February, 1994, when I worked at Chilton on Electronic Component News (ECN). More recently, I've been trying my hand at writing scripting additions and adding basic scriptability to my projects. Incidentally, most of these notes refer to pre-OS X AppleScript, so to learn more about the current version of AppleScript, leave here now, and visit these sites:

• The AppleScript home page at Apple Computer.
• The AppleScript Sourcebook edited by Bill Cheeseman.
• MacScripter

Happy scripting!

 

If you've chosen to stay and read on, be warned that this page is kind of a mish-mash. Here's what's here:

• The Philadelphia Area AppleScript Users Group (PAASUG)
• A very short review of Smile.
• Random blog entries.
• A couple of AppleScript tips.
• A few notes on writing a scripting addition (osax).
• Some notes on program linking.

Philadelphia Area AppleScript Users Group (PAASUG)

I've been attending PAASUG meetings off and on for years, and even though I write very little AppleScript these days, I always learn something new and enjoy the company of other AppleScript enthusiasts. Most recently, we have been meeting at University of the Sciences in Griffith Hall on the third Monday of every other month. As of Spring, 2004, PAASUG has its own website, designed and maintained by Maximum Computer Systems. Please check it out for more information.

May 17, 2004

The May 17, 2004 meeting featured Deivy Petrescu, who gave a talk demonstrating Smile. I took some pictures.

July 19, 2004

The July 19, 2004 meeting featuring Samuel Leidy who gave a talk on building a Multiple Entry dialog box in AppleScript Studio. I took some pictures as well as notes:

There were six regular members in attendance at tonight’s meeting, a little fewer than usual. We were glad to see two new faces as we welcomed two members of the South Jersey Apple Users Group (Frank Petrie and David Drumheller). The SJAUG has their own AppleScript SIG led by Lincoln Hansen.

PAASUG President, Ben Waldie, kicked off the meeting. He just returned from Macworld Boston where he moderated a “BOF” meeting, “AppleScript Success Stories and Q&A.” Ben reported that the buzz from Boston was about the new Automator feature of Mac OS X “Tiger.” The feeling was that Apple’s hidden agenda behind Automator was to encourage application developers to make their applications more scriptable. Ben then yielded the floor to Samuel Leidy.

Before beginning his formal presentation, Sam challenged the group with some pointed observations about the inconsistencies that have crept in to AppleScript since the advent of OS X. Few would argue that AppleScript has been in better shape now than it has been in many years. No one would want to go back to the days when it was literally years between AppleScript updates; things have certainly changed for the better. For example, AppleScript has been updated six times since the release of OS X in 2001. It’s heartening to see that Apple is taking AppleScript seriously. After all, AppleScript’s future was by means assured.

In the years immediately preceding Steve Jobs’ return, AppleScript had been languishing for years. Once Steve Jobs returned and it became clear that OS X would be largely based on the work that he had done at Next, some wondered if AppleScript would be swept away along with the other projects that Steve cut. After all, AppleScript came out of Apple after Steve left and owes nothing to Next technology.

Happily, AppleScript has, if anything, flourished since Steve’s return, and the latest example is AppleScript Studio, which permits AppleScript to be used to build Cocoa applications. When AppleScript Studio was released, it seemed a sure sign that AppleScript’s fortunes as a technology with a foundation and a future seemed secure. Yet while one now has the ability to write a Cocoa application using AppleScript alone, the language could hardly be called a peer of Objective C as it lags far behind Objective C as a language for Cocoa. While Cocoa has made room for AppleScript, AppleScript still hasn’t been seamlessly and fully integrated into the Cocoa environment.

As an example, Sam compared the functionality of “display dialog” called from an AppleScript Studio application to the same call in a vanilla script in Script Editor. To dramatize the comparison, he used a four-paragraph string. Apple has documented that the call in AppleScript Studio overrides the normal display dialog (to provide some additional Cocoa functionality), but Sam wanted to show how the Studio version is actually less flexible. While the normal display dialog was able to display all four paragraphs (by expanding its window to fit the text), the Studio version is a fixed size and only has room for three (and a half) lines of text. Clearly this dialog box was never intended to hold more than two lines of text. This was rather surprising.

Sam went on to show his own version of display dialog, which he created in Interface Builder, for use in AppleScript Studio projects. It emulates the normal display dialog’s ability to grow its window to accommodate the string passed to it. He was troubled by the necessity of reinventing display dialog, especially since Apple’s own documentation recommends using display dialog, at least for debugging. The AppleScript Studio display dialog can’t hold enough text to be very useful for debugging. For more information, visit Sam’s site. This demonstration sparked a discussion among the members about another problem with dialog buttons where sometimes button text is “pushed down” and cut off.

Sam then showed a script that used curl to download a file from a web site, which led to a discussion of the scriptability of various browsers. The consensus seemed to be that Internet Explorer was the most scriptable of browsers. The irony was bitter, and we further lamented that Apple’s own applications are often the least scriptable in their class.

Next Sam commenced the centerpiece of his presentation—an implementation of a Multiple Entry dialog box. The dialog box features an entry box for typing text and a table view for collecting and displaying the individual entries. Buttons control adding and deleting entries. Although Sam said that the dialog box was really only one part of an application, it served to demonstrate the process of making an AppleScript Studio application using Xcode and Interface Builder. Most of the time was spent in Interface Builder as Sam built the interface from scratch, creating a window, then adding buttons, a table view, label text, an editable text box, and finally “hooking up” the interface to AppleScript handlers. It was quite a good demonstration of the ease of interface creation in Interface Builder. There wasn’t time to walk through all the AppleScript handlers, but you can see the finished project in action on Sam’s demo site. Look for MultipleEntries and MultipleEntries02.

Ben concluded the meeting with a drawing for a copy of REALbasic for Macintosh (a Visual QuickStart Guide by Michael Swaine, published by Peachpit Press), and Apple-logo notepads, pens, and keychains. We wrapped up the evening by moving the meeting to The Best House (formerly The Wurst House) for hoagies, pizza, and cheesesteaks.

April 1, 2005

It's been a long time since I attended a meeting, all due to work-related scheduling conflicts, not lack of interest. At this meeting I gave a little talk about an AppleScript Studio project called Marionette that I wrote to manage this web site. It provides a centralized interface to the site's files and integrates MySQL, BBEdit, Perl, and Interarchy.

I didn't take as many pictures at this meeting as I usually do, but here are a few.

June 3, 2005

There were 7 members in attendance this evening. Deivy had a nasty cough; I hope he's feeling better!

Our presentation this evening was by Ben Waldie on the new AppleScript changes in Mac OS X 10.4 “Tiger.” Although Ben covered a lot of ground in this meeting, his presentation was necessarily constrained by time limits, and the list of changes in these meeting notes is not meant to be comprehensive. For more information, there is a wealth of info in the AppleScript 1.10 for Mac OS X - Release Notes.

Ben got things started by asking how many had already upgraded to Tiger. Not everyone, apparently. Those who had cited issues with Virex, CronniX, Carbon Copy Cloner, and Transmit. The consensus was that Tiger has its share of bugs.

Ben made a couple of miscellaneous observations. There's a bug in Mail.app: when you try to get the mailbox of a message, Mail returns “missing value.” If you are writing an AppleScript installer, use move instead of copy to put files in folders that need authentication. Copy will error silently while move will at least throw up an authentication dialog.

Ben continued by going over the changes in Script Editor, which is now at version 2.1.

The new version features an enhanced dictionary browser that can show commands by suite, containment, or inheritance, similar to what Script Debugger has long offered. The Find command, invoked with Command-F, no longer works in the dictionary, and has been replaced with a Finder-style search box. The new version will not find all text as the old one did, even text plainly visible in the window. It seems to search only in the “fields” chosen using the popup, but can only search for one type at a time, and can't search for all types. Useful sometimes, I guess. (Note that the old Script Editor still works under Tiger.) The dictionary now incorporates hyperlinks right in the dictionary, and developers can incorporate links to other terms and even sample code! A good example is the dictionary for PreFab's UI Actions 1.1.1. Interestingly, when you click on the QuarkXPress suite in the QuarkXPress dictionary nothing shows up.

You can now drag paths into a script, but this is a basically useless feature as it is a Unix path. Tsk tsk.

The Bundle Contents button allows you to see contents of a script saved as a bundle in a drawer.

The Script Editor now has some of its functionality implemented as plugins, including the dictionary browser itself. Inside the Script Editor package there there is now a plugins folder.

The new AppleScript Utility allows setting of some global preferences such as the default script editor, enabling GUI Scripting access, and controlling the Script menu.

The background app System Events has some new suites: XML, Property List, Movie File, and QuickTime.

Standard Additions has added a display alert command. The icons for “information” and “critical” are the same icon; the “warning” icon is a triangle. Display dialog now has a bulleted font for obscuring passwords as they are entered.

The new “system info” command can now get the AppleScript version, the AppleScript Studio version, and the system version as strings. You can test version numbers using the syntax “considering numeric strings.” For example, using string comparison “1.9” < “1.10” returns false. That's correct, of course, but obviously wrong in a version-number context, because 10 is greater than 9. The same comparison wrapped in “considering numeric strings” returns true.

The Finder's sort command is now available, although Copy (to the clipboard) is still not available.

There are a number of changes limiting remote Apple Events, although you can still tell a remote machine to run a remote script though.

There's a new background application called Database Events that lives in /System/Library/CoreServices. It's not running by default; issuing a tell will cause it to launch. It will then quit automatically after 5 minutes. Database Events allows you to create “databases” on the fly in memory and optionally save them as a file.

We created a simple database with no records and then experimented with adding records and changing fields. Once you have some data, you can perform queries using a standard whose clause. The structure of the database shows no concept of a table (in which all records have the same fields), and it behaves more like a collection of independent AppleScript records, in that each record can have it's own format. Because Automator has no logic built into it, Database Events would allow you to store persistent data somewhere for use in your workflow.

After Database Events, Ben moved onto another new Tiger technology, Automator. Ben wrote the book on Automator. Literally. He wrote a book called “Mac OS X Technology Guide to Automator,” which was released the day after Tiger was.

Ben ran through a quick getting-started tutorial on Automator for those of us who had never used it. Automator is an application that you use to build “workflows,” which are a series of discrete steps or “actions” chained together.

When you open Automator, you will see a list of categories and for each category, a list of the actions that pertain to it. Each action is responsible for a single task, and the actions combine to create a unique workflow. To build a workflow, select an action and drag it into the window, and set parameters, if any. Note that the output of one action should match the input of the next one, although Automator can convert some data types automatically.

You can save the result as a workflow, as an application, (double-clickable or droppable), as a “plugin” (which actually saves as an application in the appropriate folder for the application), or it can appear in the Finder's contextual menu. Saving a workflow as a folder action doesn't attach the Automator action to the folder. Rather, it creates a short AppleScript that is attached to the folder and launches the Automator action. Your Automator workflows live in Library/Automator inside your home folder.

You can create your own Automator actions in Xcode, which Ben spent about ten minutes on, walking through the steps to create a simple action that returned a parameter. Apple provides an Automator Action template in Xcode. In the Xcode project, the main AppleScript file is the heart of your action. The nib file is where you add widgets to set parameters or accept input. You link the nib file to the action using Cocoa bindings. There is an Automator palette called AM Palette in Interface Builder that is not loaded automatically. What’s more, it’s well-hidden, as it’s not in the palettes folder. The info.plist is where you control how the action behaves in Automator as opposed to what it actually does. As an example, AMAccepts determines what data types your action will accept.

Ben wound up the meeting by giving away books on FileMaker, XML, and Python. We adjourned to The Best House for pizza slices, cheesesteaks, and the biggest stromboli I have ever seen.

Here are a few pictures from the meeting.

Smile

I’ve wanted to try Smile (the AppleScript editor) for a while now. Many people like it a lot because it offers some unique features, but every time I tried it, I gave up in frustration. I just didn’t “get” it. At the time, it didn’t really matter, because I have always been a very satisfied user of Script Debugger. The most recent version I own is 2, however, and since I haven’t been doing much scripting in recent years, I didn’t feel justified spending the money to upgrade to version 3. My needs were met by using Script Editor. I wasn’t happy about it, but I could get by. With some scripting projects to do, I took the opportunity to give Smile (2.5.9) another chance. After all, there was no risk involved—Smile is free!

I was pleased to find out that Smile is really cool, but I felt that the documentation (which consists of a Getting Started PDF and a few paragraphs of online help) was rather skimpy. I can see why I was frustrated. Herewith, then, are some notes to myself on using Smile.

My first project involved opening a script saved as text into a Smile “Text” window. “Text” windows are a unique feature of Smile. In a Text window, hitting the Enter key executes the current line or the selection (compiling first if necessary) instead of running the whole script top to bottom as would normally occur in other editors (or a Smile “Script” window). I’m sure this works fine for writing a script from scratch a line at a time—but I was starting with uncompiled text

When you reach a line containing a call to a handler later on in your script, you will get the error that <<script>> doesn’t understand the <<handler name>> message. That’s because the handler hasn’t been compiled yet. To fix this, select the handler and hit Enter to compile it. Another problem with “Enter-stepping” is that Smile can’t step through any part of a code block (examples: try, end try, with timeout, end timeout, if, end if, multi-line comment, etc.) unless the line is a complete statement, so every time you reach a block, hitting Enter throws an error. To get around this limitation, you need to select the entire block and run it as a unit. Even with these annoyances, I’ve discovered that Smile has a lot of potential, although from reading these criticisms, you’re probably wondering where it is!

After my initial enthusiasm for Smile, I haven’t had much luck using it for doing real work. Even working around the inconvenience of Smile not being able to step through “if” and “repeat” blocks or into handlers, I was still stymied by weird errors. As much as I like Smile’s unique features, I don’t think it’s practical to use on a script of any length or complexity.

Update: Deivy Petrescu’s presentation on Smile at the May 17, 2004 meeting of the PAASUG gave me new respect for Smile, although my objections to it still stand. Nevertheless, it’s an amazing piece of work.

Blog Entries

Monday, March 24, 2003

Tonight I attended the first meeting of the resurrected Philadelphia Area AppleScript Users Group. This special-interest group for devotees of Apple’s scripting language AppleScript was founded in 1999 and used to meet regularly at SSI in King of Prussia. The group’s founder, Ben Waldie, changed jobs about two years ago and became too busy to keep the group going, so it’s been on hiatus for a while. He has changed jobs again and started his own company, so for the moment at least, he found enough free time to reorganize the group. We met at Springboard Media (an Apple reseller) in downtown Philadelphia. Special thanks to Everett and his staff for letting us use the store after hours. We were warmly received, and one of the staff, Jason, attended the meeting. For more information, please visit our group’s web site. AppleScript is still one of my favorite programming languages even though I’m not using it much at the moment; I have a few random notes here.

Ben showed off his new 17-inch PowerBook, which only began shipping a few weeks ago. Surveying the sleek titanium PowerBooks and iBooks the others were sporting, I felt a strange sense of pride in having by far the oldest PowerBook of any attendee, a sickly 1998-era Wall Street. I described my PowerBook’s ailments to Jason, and he helped me come to the conclusion that it just isn’t worth fixing.

Wednesday, May 21, 2003

Monday night I attended the second meeting of the revived Philadelphia Area AppleScript Users Group held at Springboard Media. Leonard Rosenthol of PDF Sages spoke about scripting Adobe Acrobat. Afterwards most of us went to Roosevelt’s Pub at 23rd and Walnut for bonding and brewskies. The food was excellent, and it was a nice place to gather and talk. I had a delicious blackened tuna-steak on a kaiser roll.

Tuesday, November 18, 2003

Last night I attended the bimonthly meeting of the Philadelphia Area AppleScript Users Group held at Springboard Media in Philadelphia. Thirteen people turned out for this one, probably a record. One discussion unrelated to AppleScript had to do with someone using the utility "top" to discover why his computer was running so slowly. He discovered that MouseWorks (the software supplied with Kensington mice and trackballs) was using over 50% of the processor. Hey, I thought, I have MouseWorks and my computer is sure slow. Maybe that’s it. At the first opportunity I ran top, but the only thing sucking cycles was top itself. I guess I can’t get a speed boost that easily.

Saturday, December 21, 2002

Some interesting AppleScript news: Apple’s Script Editor has been ported to Cocoa and released to an unsuspecting world as a beta (v20). I can’t say I was waiting breathlessly for this development, but I was grateful nonetheless. Any indication that Apple cares about AppleScript is more than welcome.

When I fired up the new Script Editor, I didn’t know what to expect. Would it be an improvement over the original Script Editor, an application so lame and limited that Apple gave it the creator type “Toy Surprise”? (That’s not to say that Script Editor is useless. But using Script Editor to write AppleScripts is like using SimpleText to create your web site--possible, but oh so painful.) Hmm. The icons looked strangely familiar. They seem borrowed from Apple’s Project Builder, and the extremely brief release note implies that they aren’t final, saying "note that all of the icons in this version are place holders and will be changed in the final version." Oh, goody. New icons coming!

To test the new Script Editor, I simply chose the command I most hated in the old Script Editor: “Open Dictionary.” In the old version, Script Editor would scan all mounted drives to find every application--an operation that could take many minutes--before presenting you with a list to choose from. It was infuriatingly bad design. But the new Script Editor surprised me. Guess what? It works exactly the same way.

I don’t really care what it does, because I don’t really use it, but it just amazes me that anyone at Apple could choose this command even just once and think it works correctly. No one wants to open the dictionary of every application. Just give me a dialog box and I’ll find the application I want to open. Criminy.

On the brighter side, Apple has incorporated some important improvements into Script Editor--and not just added new icons. See here for details.

I may whine about Script Editor, but it really is exciting to see it rewritten under Cocoa. Bravo.

“Classic” AppleScript

These random notes refer mostly to pre-OS X versions of AppleScript. I guess you can tell I haven’t been doing much scripting lately.

Tips

Setting font sizes in Script Debugger

I was working on some scripts in early 2004 using Script Debugger 3 and wanted to set the font sizes to 10 points instead of the default 12. I was unable to make the change “stick.” For some reason, you must make these changes using Script Editor.

 

When is a string not a string? When it’s “styled text.”

I was trying to pass the error message generated by a try block to the sendmail osax, but the osax choked on it. Finally I realized that the try-block’s error message is not a plain-text string, but is actually styled text! I was very surprised to discover this (I mean, why is it styled?) and never noticed it before, because (I suppose) whatever I’ve fed it to (display dialog, for example) coerces it to plain text as need be.

 

try

foo of bar

on error errMsg number errNum

end try

 

errMsg is of class STXT, a record with two fields: class ktxt is the text and class ksty is the style data. To convert this to a plain text string:

 

set errMsg to (<<class ktxt>> of (errMsg as record))

 

Now sendmail will no longer choke on errMsg.

Apple Event Programming

Writing a Scripting Addition (osax)

Someday this may evolve into a full-blown tutorial about how to write a scripting addition with enough detail so even newbies can do it, but for now it has a lot of holes. I’ll keep working on it.

 

The best single source for learning how to write a scripting addition is Anatomy of a Scripting Addition by Mark Alldritt. This one article covers just about everything (with source code of an aete resource and code for creating a code resource using Code Warrior), but as a beginner, there were parts I just didn’t understand. Another source is Apple’s AppleScript SDK (available via FTP [50 Mb]), which contains examples.

To get started, what I recommend is to write a very simple application and add your Apple Event code to the application. Because it’s tedious to debug a scripting addition (actually, it’s impossible to debug it. You have to compile and save it anew each time you change it, and I’m sure you can’t use source-level step debugging.). Embedding your code initially inside an application makes development and debugging simple.

Making a PPC Code Resource

All the examples I found were for 68K code resources, so with some help from meeroh on the newsgroup comp.sys.mac.codewarrior, I was able to figure it out. I wrote:

Then I discovered Tech Note TN1164, "Native Scripting Additions," which explains how to do this. I learned that a native osax is a shared library, not a code resource, and there is no "Main" entry point. You write a function that first calls __initialize, passing it a pointer to a CFragInitBlock. Obtain a AEEventHandlerUPP by calling NewAEEventHandlerUPP, passing your event handler’s name. Then load your event handler(s) using AEInstallEventHandler. Put this function’s name in PPC Linker -> Entry Points -> Initialization. Write a function that cleans things up--in this case call AERemoveEventHandler, DisposeAEEventHandlerUPP, and __terminate() at the end of your function. Put the function’s name in PPC Linker -> Entry Points -> Termination. This worked fine.

For anyone who’s interested, see Tech Note 1164. Also see UniversalOSAX.sit for Eric Grant’s CodeWarrior post-linker plugin that can create a universal osax that runs on 68K and PPC from System 7 to OS 10.1. I didn’t use the plugin, but the package includes the source of Marco Piovanelli’s "AppleScript Formatting" osax, which I was able to use as an example. Check out the Carbon target.

The ’aete’ Resource

The aete resource is what defines the Apple Events your application handles, and also provides the entries in the application’s dictionary. The canonical documentation is Inside Macintosh: Interapplication Communication: Chapter 8: Apple Event Terminology Resources. Available in HTML or Adobe Acrobat format. Everything you need to know is in here, but I sure couldn’t learn how to write an aete from this documentation alone.

“According To Script” columns in develop by Cal Simone of Main Event Software.

• According to Script: Designing a Scripting Implementation (develop, Issue 21, March, 1995; HTML or download Acrobat version.)
• “According to Script: Thinking About Dictionaries” (develop, Issue 23, September, 1995; HTML or download Acrobat version.)
• “According to Script: Steps to Scriptability” (develop, Issue 24, December, 1995; HTML or download Acrobat version.)
• “According to Script: Properties and Preferences” (develop, Issue 25, March, 1996; HTML or download Acrobat version.)
• “According to Script: Vocabulary Advice” (develop, Issue 29, March, 1997; HTML only.)

I use the Rez format to write an aete. There are a number of tools for doing this, and I’ve looked at the free ones. Resourcerer, which is not free, is what many recommend, although I have never seen it. For more tools, see the Programmers’ Tools page of the AppleScript Sourcebook.

Program Linking

I needed to brush up on Program Linking recently for a project which required simple operations on files on a remote computer (reading, writing, and deleting text files). Program Linking allows you to send commands to applications running on a remote computer. To activate it, open the File Sharing control panel and click the Start button. As of OS 9, you can link to programs using TCP/IP as well as AppleTalk.

Apple has produced an excellent guide called “Program Linking Over IP” that is available on their AppleScript Guidebook page. It covers just about everything in detail, so there’s not much I can add here. What prompted me to write this section was that I had a lot of trouble getting Program Linking to work reliably. Since I did get it working finally, I was hoping to offer some solutions based on my experience, but once I corrected the syntax errors in my script and restarted, all the problems mysteriously vanished, so I chalk the trouble up to teething pains. I think if you have any serious syntax errors in your script that makes authentication fail, then program linking gets confused and won’t clear the error until you restart.

Program linking requires the remote user of an application’s services to authenticate herself. Once logged in via the program linking approval dialog, you won’t need to re-enter your username and password until one of the computers is restarted. The Keychain can store the password in order to bypass the dialog. If the user on the host machine is deleted while a program linking connection has been established, you will be warned that there is a connection in place. Then when the script is run or recompiled, you will prompted for a user name and password.

Authentication was the area where I had the most trouble. Sometimes the user was not recognized as having an account on the remote machine, and sometimes the password was rejected. If you’re sure you have the username and password correct, then try restarting.

Worst of all, sometimes the machine could not even be found on the network (throwing a -916 error). I tried both versions of the syntax (AppleTalk and TCP/IP), but neither worked reliably.

• Using the computer’s name as seen on an AppleTalk network:

  tell application "Finder" of machine "<computer’s name>"

   

  Example:

  tell application "Finder" of machine "Bill Gates’ iBook"

   

  If the remote computer is in a different AppleTalk zone, then you must include the zone, otherwise it’s optional:

  tell application "Finder" of machine "Bill Gates’ iBook" of zone "Evil Empire"

   

• Using the computer’s IP address ("Enable Program Linking Clients to connect over TCP/IP" must be checked in the File Sharing control panel to use IP addresses):

  tell application "Finder" of machine "eppc://<IP address>"

  (By the way, “eppc” stands for Event Program to Program Communication.)

   

  Example:

  tell application "Finder" of machine "eppc://127.0.0.1"

  end tell

   

I ended up using the IP address syntax instead of the AppleTalk name, even though we are still routing AppleTalk on our network. If you are having trouble with the AppleTalk syntax, and the machines are on the same zone, try removing the reference to the zone.

What is not covered explicitly in Apple’s documentation is how to use Scripting Additions on the remote machine. Since Scripting Additions are not applications, there doesn’t seem to be any way for them to be targeted using program linking. The solution is to place your Scripting Addition command inside a Finder tell block.

 

Set a variable to the remote Finder:

set remote_Finder to application "Finder" of machine "Bill Gates’ iBook"

 

Put your Scripting Addition command inside a remote Finder tell block:

tell remote_Finder

say "Where do you want to go today?"

end tell

 

To use an application on the remote Mac, you must have a copy of the application on the home Mac as well in order for the script to compile. You can turn Program Linking on or off for each application on the remote Mac by choosing Get Info and selecting the Sharing option. The Finder, however, doesn’t have the Sharing option to "Allow remote program linking," and, since it is always running, you don’t need to start it.

As I mentioned, the AppleScript Guidebook module is an excellent guide. In addition, see Apple Tech Note 1176 for more information.

Posts in “AppleScript”

November 1, 2006