Thanks for the reply, I have updated the article with your recommendations. Also, the 3-line AppleScript I was using was unnecessarily long, this has been corrected.

Putting a large AppleScript in a separate source-file makes sense. But in my opinion, for 1-5 line snippets, embedding the AppleScript right in the coca source code is the best way to go. It’s clear exactly what the code does, because it’s all right there — no cross-referencing in separate .scpt files. Executing a .scpt from your application’s bundle is conceptually no different from executing a perl script, or any other type of script for that matter. The beauty of NSAppleScript is that it lets you put AppleScript code right in your Cocoa code, which is very useful. I know Apple does this, because the FrontRow executable has strings of AppleScript code inside it.

What you say about plugins and threads seems pretty close to what I was feeling when I first wrote this article. AppleScript interfaces do seem to be very stable and a lot of them have been around longer then Coco interfaces. But since then, few things have happened, and all of them have reduced the amount of AppleScript code I use.

I begun using threads more heavily, which made using NSAppleScript much more of a hassle. Also, code that used to work, and was thread-safe except for NSAppleScript was suddenly broken. This made me wary of using NSAppleScript in the future. Hopefully things will be thread-safe in the future, but I’m not holding my breath.

I learned about NSTasks, and have more experience with Cooca. This has made other ways of getting things done, including buggy plugins + reverse-engineered interfaces, a bit more manageable for me.

I want to do things with a program that there is simply no way to do with a program’s AppleScript interface.

Also, the method described above for reading out the NSAppleEventDescriptor is a bit more complicated than is necessary most of the time. If you’re expecting a single string, just use stringValue. So my version would be:

In an applescript text file called getMessage.applescript:

tell application ”iChat”
get status message
end tell

In a Cocoa / Objective-C class:

NSString *scriptPath = [[NSBundle mainBundle] pathForResource: @”getMessage” ofType: @”scpt” inDirectory: @”Scripts”];
//It doesn’t matter in which group in XCode you put getMessage.applescript, it will be compiled to Scripts/ getMessage.scpt in the bundle
NSDictionary *errorDict;
NSAppleScript *theScript = [[NSAppleScript alloc] initWithContentsOfURL: [NSURL fileURLWithPath: scriptPath] error: nil];
NSAppleEventDescriptor *resultDescriptor = [theScript executeAndReturnError:&errorDict];
NSLog([resultDescriptor stringValue]);

I’ve stopped using AppleScript to communicate with Adium — instead I am writing an Adium plugin. I’m also using a private/unsupported interface to interface with iChat, because it is much more powerful then AppleScript.

If you’re interested, there’s a third-party Apple event bridge currently in development for ObjC, allowing you to skip AppleScript and talk to applications directly:

http://appscript.sourceforge.net/objc-appscript.html

e.g. To get iChat’s status message:


// Generate glue: osaglue IC iChat
OSErr err = noErr;
ICApplication *iChat = [[ICApplication alloc] initWithName: @"iChat.app"];
ICGetCommand *getStatusCmd = [[iChat statusMessage] get];
NSString *statusMessage = [getStatusCmd send];
if (statusMessage == nil) err = [getStatusCmd errorNumber];


HTH