Sending Apple Events from a Cocoa App

[Nutter]

I'm a fairly newb Cocoa programmer looking to send Apple Events to iTunes (and receive responses in some cases).

As I understand it, I have four options:

Use the Carbon routines for this, which look really scary.

Use NSAppleScript to generate Apple Events from AppleScripts. AFAIK I won't be able to use compiled scripts in cases where I want to use variables in my App as part of the script, so performance will suffer.

Use NSAppleEventDescriptor with NSAppleScript to generate Apple Events in code. I'm not sure how difficult this would be.

Use a third-party Objective-C wrapper, such as this:
http://homepage.mac.com/nathan_day/pages/s...plescriptobject (http://homepage.mac.com/nathan_day/pages/source.xml#ndapplescriptobject)

Now, it seems to me that option 4 is the easiest way to do this with reasonable performance, as it would let me effectively pass variables into compiled scripts. However, I'm reluctant to bung someone else's code in my App without properly considering the alternatives. I'm also worried that I'd be able to get better performance by building the events programmatically, I'm just not sure I'm up to it yet.

To top it all off, I suspect that I'll need to send the events asynchronously to avoid bringing my GUI to a grinding halt, and keep it from crashing if (when) iTunes does. Is that even possible if I'm using high-level code that works from an AppleScript?

Does anyone have any advice?

[kainjow]

I use a class called AEVTBuilder (http://www.cocoadev.com/index.pl?AEVTBuilder) that makes it really easy to build Apple Events. Much faster than using AppleScripts too.

[Nutter]

Thanks, that looks pretty smart. Should take all the guesswork out of it!

To follow up on my last point, in your experience is it worth sending events asynchronously, or is it not worth the extra design that would involve?

[kainjow]

To follow up on my last point, in your experience is it worth sending events asynchronously, or is it not worth the extra design that would involve?
I just make the code threaded, which is a lot easier to do than making it asynchronous.

[Nutter]

I was afraid you were going to say that. :rolleyes:

Should I just put the Apple Events stuff in a separate thread, or should I stick all the interface stuff in its own thread? I suppose the latter would make more sense, but then, I don't know much about threading (yet).

Thanks, I appreciate the help.

[kainjow]

If you don't know much about threading, read and learn about it first, or else you will have nightmares :)

FYI, when using Cocoa, never access interface objects directly from another thread.

[Nutter]

I think that's backwards -- I'm likely to have nightmares after I read about threading... ;-)

Thanks.

[Nutter]

Sorry for bringing this thread back from the dead, but I'm a little further on now and have another question.

How do I generate an Apple Event that uses the result of a previous Apple Event?

For example, here's the AppleScript code I'm trying to duplicate:

tell application "iTunes"
set x to current track
play x
end tell

I send an event to iTunes asking for the current track, and it sends back an Apple Event Descriptor containing three nested objects.

When I subsequently send a play message to iTunes, for example, I have to pass the same three nested objects that I received as a result of the previous message. How do I do this, short of actually parsing the return event descriptor and manually generating every part of the event, which seems to me to involve making unnecessary assumptions?

Basically, I need to insert the return descriptor into my new event, right? Is this possible using AEVTBuilder?

I think I'm going to go and lie down now. :cool: