I suspect that what Apple have come up with is an extended framework based on the NSApplescript class. This existing class allows you to load, compile and execute Applescript from within a Cocoa application. However, it's not much fun to use if you want to do anything relatively granular (like get the name of the current iTunes track).
By using a proxy object (as you suggest) with some kind of KVC error checking based on the calling dictionary, I guess you get close to what they're s'pposedly offering.
The fun will start here tho' when working with those, uh, slightly more obtuse Applescriptable applications. There are plenty of Applescript dictionaries out there that baffle even experienced script coders. How that'll all work when you're one level removed behind a toll-free bridge could be entertaining...
by Scott — Dec 13
I suspect that what Apple have come up with is an extended framework based on the NSApplescript class. This existing class allows you to load, compile and execute Applescript from within a Cocoa application. However, it's not much fun to use if you want to do anything relatively granular (like get the name of the current iTunes track).
By using a proxy object (as you suggest) with some kind of KVC error checking based on the calling dictionary, I guess you get close to what they're s'pposedly offering.
The fun will start here tho' when working with those, uh, slightly more obtuse Applescriptable applications. There are plenty of Applescript dictionaries out there that baffle even experienced script coders. How that'll all work when you're one level removed behind a toll-free bridge could be entertaining...