on 2008-03-03 5:31 PM, Eric Schlegel at [EMAIL PROTECTED] wrote: > The Accessibility API (_not_ AppleScript) is clearly the right way to > go here. With Accessibility you can get information about the windows > in other processes, including their titles, and then compare those > titles to your desired window title. AppleScript is not sufficient for > this task because not all applications implement the AppleScript > scripting interface that you'd need to get this info.
I believe this isn't quite accurate. The GUI Scripting feature in AppleScript, introduced publicly in Mac OS X 10.3, works through the System Events application and is based directly on the Accessibility API. You can do most things with GUI Scripting/AppleScript/System Events that you can also do with the Accessibility API. In those cases where you can't use AppleScript, I generally see it as a bug in the System Events implementation of GUI Scripting. Of course, for writing program code, using the Accessibility API is a much more direct approach than embedding a script in your application package or constructing Apple events. To be a little more technical about this: The System Events application in /System/Library/CoreServices contains an AppleScript terminology dictionary which serves as the scripting interface for the Accessibility/GUI Scripting features implemented in System Events. According to that dictionary, another application's 'process' is, to System Events, an AppleScript object having properties that consist, for the most part, of the UI elements (such as windows) in the target application's process. Just as an AppleScript script targeting the Finder can find all the properties of a 'Finder window' object, a script targeting System Events can find all the properties of a 'process' object. The ability of System Events to do this with its terminology dictionary does not depend in any way on whether the target application is scriptable. What it does depend on is whether the target application properly implements the Accessibility API. There are still many applications that do not implement the Accessibility API in their UI elements, or do not do so for all their UI elements. Last time I looked, Apple's own FileMaker Pro was in this category, as were a number of Adobe products, as well as miscellaneous other applications. This is usually because these applications use old code libraries for their UI elements that have not been updated with Accessibility API capabilities, as the standard Carbon and Cocoa frameworks were in Mac OS X 10.2, or because they implement custom UI elements without bothering to include support for the Accessibility API. So, when a target application doesn't work with GUI Scripting, it also probably won't work with the Accessibility API -- except in those rare cases where GUI Scripting doesn't work because of a bug in System Events. -- Bill Cheeseman - [EMAIL PROTECTED] Quechee Software, Quechee, Vermont, USA www.quecheesoftware.com PreFab Software - www.prefabsoftware.com _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
