On May 26, 2009, at 8:30 PM, Mark Lively wrote:
> On May 26, 2009, at 5:45 PM, Bill Cheeseman wrote:
>
>> The technology for doing this is called "GUI Scripting," and it
>> works by sending AppleScript commands to the System Events
>> application. That application implements a bunch of AppleScript
>> commands that know how to control the user interface elements in
>> running processes. One of those commands is called 'click.' One of
>> the parameters of the 'click' command is 'at.' According to the
>> System Events application's AppleScript terminology dictionary,
>> when you use the AppleScript GUI Scripting command 'click at', you
>> should use "the { x, y } location at which to click, in global
>> coordinates." This means you should use the screen coordinates,
>> where the origin {0, 0} is at the bottom left corner of your main
>> screen.
>>
> Top left. Unlike almost everything else in the world.
Oops! Mark is right.
>> The only way to know where a button is located is to ask the
>> application that owns the button where it is right now. Application
>> windows can be moved around, and only the application knows where a
>> button in one of its windows is currently located. You can find
>> this out with GUI Scripting by asking the System Events application
>> to tell you where the target application's window is currently
>> located, and where in that window the button is located. Then you
>> can convert that location to the global coordinates of the button
>> and use the 'click at' command.
>
> There are a very few applications where gui scripting cannot hit the
> button. Adobe is infamous for this.
Right. Unfortunately, 'click at' doesn't help in these cases, because
Apple implemented the 'click at' command to find the button at the
given location first, then click the button. Apple should have
implemented it to actually click at the indicated screen coordinates
no matter what is there. That would have solved the Adobe problem.
--
Bill Cheeseman
[log in to unmask]
|
