Re: iTunes and AppleScript
Re: iTunes and AppleScript
- Subject: Re: iTunes and AppleScript
- From: Matt Neuburg <email@hidden>
- Date: Thu, 24 Aug 2006 18:32:33 -0700
- Thread-topic: iTunes and AppleScript
On Thu, 24 Aug 2006 10:45:51 -0700, John Stiles <email@hidden> said:
>We've experimented with code which used NSAppleScript to communicate
>with iTunes, like so:
>
> NSAppleScript* script = [[NSAppleScript alloc] initWithSource:
> @"try\n"
> "with timeout of 1 second\n"
> " tell application \"iTunes\"\n"
> " next track\n"
> " if player state is playing then\n"
> " get name of current track\n"
> " end if\n"
> " end tell\n"
> "end timeout\n"];
>
> NSDictionary * error = NULL;
> NSAppleEventDescriptor* result = [script
>executeAndReturnError:&error];
>
>Normally this works great and everyone is happy.
Really? It shouldn't compile (in AppleScript) at all - you've got a "try"
without a matching "end try".
>However, in some instances, iTunes will put up a dialog (imagine the
>next track is purchased from the Music Store and you're not logged
>in, for instance).
>In this case, the code blocks for several minutes, despite the
>timeout conditions inside the script.
>Is there a workaround? Could this be solved if we used the lower-
>level AppleEvents APIs, which theoretically would give us more fine-
>grained control?
No, I don't see what difference that would make. Raw events are not "finer
grained" (that's just something you made up). You could rewrite using raw
Apple events but you would be sending exactly the same Apple events with
exactly the same results. Basically, sucky behaviour by a scriptable app is
sucky behaviour by a scriptable app. The iTunes people should have given yo
some kind of "without annoying dialog" option. But they didn't. m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden