• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Play Playlist in iTunes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Play Playlist in iTunes


  • Subject: Re: Play Playlist in iTunes
  • From: "Michael Ash" <email@hidden>
  • Date: Thu, 2 Oct 2008 23:08:47 -0400

On Thu, Oct 2, 2008 at 6:35 PM, has <email@hidden> wrote:
> Michael Ash wrote:
>
>> On Wed, Oct 1, 2008 at 10:16 PM, Mr. Gecko <email@hidden> wrote:
>>>
>>> I think I would just use this AppleScript call
>>> [[[NSAppleScript alloc] initWithSource:[NSString stringWithFormat:@"tell
>>> application \"iTunes\" to play playlist \"%@\"", [self replace:@"\""
>>> with:@"\\\"" source:[sender title]]]] executeAndReturnError:nil];
>>> Works fast enough for me and it would work with " because I use my
>>> replace
>>> function to make it \".
>>
>> You'll also want to replace \ with \\ (make sure you do this *before*
>> you replace " with \") and *possibly* some others as well, I'm not
>> completely familiar with exactly what AppleScript allows in strings.
>> You may also have problems with non-ASCII characters, as AppleScript
>> is notoriously Unicode-unsavvy.
>
> AppleScript 2.0 in Leopard is fully Unicode; older versions could handle
> Unicode strings, but the source code itself used your system's primary
> encoding (e.g. MacRoman, MacJapanese; a classic Mac OS throwback).

Good to know!

> That said, code generation is fundamentally evil (unless you're in Lisp,
> where it's completely normal). If you need to parameterise an AppleScript,
> define an AppleScript handler that'll receive your values as parameters,
> then pack your ObjC values into NSAppleEventDescriptors and pack those into
> an event descriptor that calls your handler via -[NSAppleScript
> executeAppleEvent:error:]. You can probably find some examples online if you
> rummage around, e.g. there's one in appscript's subversion repository that
> uses objc-appscript's AEMCodecs class to do ObjC<->AEDesc conversions (it's
> rather more powerful than OS X's anaemic NSAppleEventDescriptor class).

A good point, I should have thought of that. (I think I mentioned this
in another message to this list quite recently, in fact, but it
slipped my mind for this one.) I advocate against using AppleScript at
all, but if you need to use parameterized scripts then this is
definitely the way to do it.

>> Last time I had to do something like this (although it was
>> considerably more complex), I built a library to make it easy to build
>> raw Apple Events to mimic AppleScript without the mess that comes with
>> actually using AppleScript itself. If you want to check it out, you
>> can find more information about it here:
>>
>> http://www.cocoadev.com/index.pl?AEVTBuilder
>
>
> Neat. FWIW, objc-appscript lets you build and send events using straight
> ObjC method calls in both human-readable and raw four-char-code forms, e.g.:
>
> - using human-readable syntax:
>
>        // tell application "TextEdit" to word 1 of document 1
>
>        // To generate glue: osaglue -o TEGlue -p TE TextEdit
>        #import "TEGlue/TEGlue.h"
>
>        TEApplication *textedit = [TEApplication applicationWithName:
> @"TextEdit"];
>        TEReference *ref = [[[[textedit documents] at: 1] words] at: 1];
>        NSError *error;
>        id result = [ref getItemWithError: &error];
>
>
> - using raw four-char codes
>
>        // tell application "TextEdit" to «class cwor» 1 of «class docu» 1
>
>        #import "Appscript/Appscript.h"
>
>        AEMApplication *textedit = [[AEMApplication alloc] initWithName:
> @"TextEdit"];
>        AEMQuery *ref = [[[[AEMApp elements: 'docu'] at: 1] elements: 'cwor']
> at: 1];
>        AEMEvent *evt = [textedit eventWithEventClass: 'core' eventID:
> 'getd'];
>        [evt setParameter: ref forKeyword: '----'];
>        NSError *error;
>        id result = [evt sendWithError: &error];
>        [textedit release];

That is nice, and is probably a better way to go for something like
this. The advantages of AEVTBuilder would be:

- Smaller code (I assume). Under 300 lines, and really just a really
weird wrapper around NSAppleEventDescriptor.

- Syntax looks a lot like the debugging prints you get when you set
the magic environment variables. This is the main reason I made it.
Since I have a very poor understanding of Apple Events, I wanted to be
able to apply rote copying as much as possible, and this let me do it.

- Not that anybody cares anymore, but AEVTBuilder should work back to 10.2.

The much greater functionality provided by objc-appscript presumably
makes it a better choice for many tasks.

Mike
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Re: Play Playlist in iTunes (From: has <email@hidden>)

  • Prev by Date: re: Core Data undo grouping
  • Next by Date: Re: Play Playlist in iTunes
  • Previous by thread: Re: Play Playlist in iTunes
  • Next by thread: Re: Play Playlist in iTunes
  • Index(es):
    • Date
    • Thread