Re: UI Scripting PowerMail
Re: UI Scripting PowerMail
- Subject: Re: UI Scripting PowerMail
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 12 Oct 2004 11:26:02 -0400
on 2004-10-12 10:28 AM, Mikael Byström at email@hidden wrote:
> Shane Stanley said:
>> The gain is that _sometimes_ we can still script things that developers
>> haven't given us access too. It's a method of last resort, not a serious
>> alternative.
>
> But, like in my case, what is the limitation? Is it a given that even if
> you can get a UI elements value, that you can't set it? Is it a given
> that you can't emulate typing in a field connected to an UI elements
> value? Or is it dependent on how the app in question actually handles
> events internally vs externally? Can we expect things to improve in Tiger
> you think?
> Being new to UIS I'm trying to understand the general limitations here
> and adjust my strategies. Thanks for sharing your knowledge and experience.
In my view, GUI Scripting is in fact a serious alternative.
But Shane is correct that it should be your last resort -- or at least your
second resort. The reason is that a good built-in application scripting
implementation is usually custom fitted to the application's data and
functionality, so it works faster and sometimes with greater power (for
example, when using "whose" clauses) than any alternative scripting
approach.
GUI Scripting can be slower to execute, especially when it actually redraws
the GUI in the course of doing its work. In addition, it is limited in
functionality to things that the application implements through its UI
elements (menu items, buttons, etc.). Some functionality of some
applications may not be available through its UI elements, at least not in a
way that GUI Scripting can access.
But when you're working with a target application that doesn't support
ordinary AppleScript for your tasks, you may have no choice but to use GUI
Scripting. There is nothing inherently wrong, bad or unreliable about GUI
Scripting. It is based directly on Apple's accessibility API, which calls
into code that Apple has built into essentially all of its standard UI
elements in Carbon and Cocoa. Apple is serious about accessibility, and this
API is expected to work correctly and with as much speed as they can wring
out of it. In most respects, an application developer doesn't have to do
anything to make an application "accessible" other than to use standard
Carbon or Cocoa UI widget code. This is why most Mac applications magically
became "accessible" in Mac OS X 10.2 Jaguar, even though the application's
own code had not been revised. (This is also why some well-known long-time
Mac favorites are not yet particularly responsive to GUI Scripting -- they
use old UI widget code that is not accessible.)
There are certain areas where GUI Scripting doesn't currently work right or
at all. For example, 'set position' seems to have problems in GUI Scripting
even though it works correctly as an accessibility API call, and there are
many UI element attributes that yield no result or an incorrect result in
GUI Scripting when they correctly yield a reference to another UI element or
an array of UI elements in an accessibility API call (for example, the
"AXParent" and "AXChildren" attributes). I am confident that we will see
incremental improvements in areas like this in Tiger, as well as some
fundamental changes that will add still more power to GUI Scripting.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden