Christopher Nebel wrote:

Anyone know how to get the index of the current iTunes track using Scripting Bridge? With Applescript, it's as simple as "tell iTunes to return index of current track", but iTunes SB has no such property (well, there is one, but it only refers to the index of the current playlist). It seems the iTunesTrack index property is simply missing...? Or am I missing something?


What's missing is the line in iTunes' dictionary that says that tracks have an "index" property in the first place. Scripting Bridge takes the dictionary at its word, and therefore, no -[iTunesTrack index] accessor. Ultimately, it's an iTunes bug.

While it's true that iTunes dictionary is less than 100% accurate in its description of its Apple event API, Scripting Bridge deserves its share of the blame for ignoring the realities of AppleScript's world.

In this particular case, AppleScript ignores the hierarchical or type information given in dictionaries (historically supplied for documentation purposes only), so minor mistakes in these areas often go unnoticed for years by application developers since they don't cause errors in AppleScript. (Though by all means submit bug reports on them, as documentation errors are still errors, and best fixed.) It's Scripting Bridge that chose to be different here, and use this information for runtime purposes as well - even with the knowledge that it was less than 100% reliable.

Nor do dictionaries actually have to be in error in order to flummox Scripting Bridge this way. Given the nature of the dictionary format (particularly the older aete format), there are times when it merely isn't practical and/or convenient to provide comprehensive hard-coded type information. For example, here's a perfectly legal AppleScript:

        tell application "Finder"
get name of every item of entire contents of folder "Documents" of home
        end
        --> {"Adobe Fonts", "AdobeStockPhotos", "ashopl.pdf", ...}


plus the objc-appscript equivalent, demonstrating that this behaviour is entirely repeatable on other platforms:

        #import "FNGlue/FNGlue.h"

        // To create Finder glue: osaglue  -o FNGlue  -p FN  Finder

        int main (int argc, const char * argv[]) {
                NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

FNApplication *finder = [[FNApplication alloc] initWithBundleID: @"com.apple.finder"];
        
FNReference *ref = [[[[[[finder home] folders] byName: @"Documents"] entireContents] items] name];
        
                NSLog(@"%@", [[ref get] send]);
        
        [finder release];
        [pool drain];
        return 0;
        }

Result:

        2008-03-10 19:29:01.505 FinderTest[17031:10b] (
            "Adobe Fonts",
            AdobeStockPhotos,
            "ashopl.pdf",
            ...
        )

        The Debugger has exited with status 0.


And here's the Scripting Bridge equivalent, having the same tizz as before (only at runtime, since I'm using Ruby+RubyCocoa instead of ObjC to show it's not just a compile-time problem):

        #!/usr/bin/ruby

        require 'osx/cocoa'
        include OSX
        OSX.require_framework 'ScriptingBridge'

app = SBApplication.applicationWithBundleIdentifier_("com.apple.finder")

puts app .home .folders .objectWithName_ ('Documents').entireContents.items.arrayByApplyingSelector_(:name)

# ERROR: Can't get Objective-C method signature for selector 'items' of receiver #<OSX::SBObject:0x229728 class='SBObject' id=0x5662a0> (OSX::OCMessageSendException)


Even something like this:

tell application "Finder" to get (original item of item "somefile alias" of home)

is perfectly legal in AppleScript's world, since it's up to the server (the target application), not the client, to decide if and how a given query should be resolved. But again, don't expect it to work in Scripting Bridge.


In other words, while pointing out that iTunes' dictionary has a minor bug in it may be technically correct, it completely ignores the much larger problem: Scripting Bridge's bone-headed insistence on speaking Apple events the way it _thinks_ they should be spoken, rather than the way they _actually_are_.


has
--
Control AppleScriptable applications
from Python, Ruby and ObjC:
http://appscript.sourceforge.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to