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]
