On May 27, 2009, at 9:56 AM, Bill Steele wrote:

>> When you refer to applications that "don't enable UI events," do  
>> you mean applications that don't support AppleScript?
>>
>
> The few examples of System Events scripting I have found wrap the  
> commands in "if UI events enabled."  From this I infer that some  
> applications don't. In those that do I gather I can use
>
> click radio button "Yes" of (bladiblah)
>
> But otherwise I have to click on {x,y]

Ah, I should have understood what you're asking. To use GUI Scripting  
(in other words, to send most of the AppleScript commands in the  
Processes suite of the System Events application), you must first turn  
on the "Enable access for assistive devices" setting in the Universal  
Access pane of System Preferences. Alternatively, you can turn on the  
"Enable GUI Scripting"  setting in AppleScript Utility, which controls  
the same system setting.

There are almost no applications that do this for you, so most people  
who use GUI Scripting turn on the setting manually in System  
Preferences or AppleScript Utility and just leave it on all the time.

It is possible to write an AppleScript script that turns the setting  
on and off automatically. I explain how in the Peachpit Press book  
that Sal Saghoian and I published in December, AppleScript 1-2-3.

>> 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.
>
> Knew all that. My question was, How to find X and Y.

Use GUI Scripting commands to get the 'position' attribute of the user  
control you're targeting. If the target application works properly, it  
will return the position in the form '{x, y}.' You can also get the  
'size' attribute of the user control, then do some arithmetic to make  
sure you 'click at' the center of the user control.

But there is almost never any reason to go to all this trouble, for  
reasons I indicated. If clicking the button directly doesn't work (as  
it doesn't in some applications), then getting the position and size  
of the control probably won't work, either. And even if it does,  
'click at' will only do what you could have done yourself, click the  
user control that happens to be at that location. If clicking the  
button doesn't work, it therefore won't work when you use 'click at',  
either. In short, there is usually no solution for user controls that  
don't properly support the 'click' command. This is a well-known  
limitation of GUI Scripting, not yet fixed by Apple.

Several years ago, I gave the responsible Apple engineer some code  
that would make 'click at' really click at the specified screen  
coordinates, instead of just finding the user control at that location  
and clicking it directly. If he had implemented my code, 'click at'  
would work in all applications as a workaround for directly clicking  
an unresponsive user control. Alas, he didn't have enough time to make  
the change.

>> 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.
>
> And the syntax for asking that question would be? Can't find  
> anything in the System Events dictionary that looks like it.

Here's an example. Try it in Script Editor, It works (if you've turned  
on GUI Scripting/assistive devices).

activate application "AppleScript Utility"
tell application "System Events"
	tell process "AppleScript Utility"
		-- insert GUI Scripting statements here
		try
			tell button "Set Up Actions..." of window "AppleScript Utility"
				set {xPosition, yPosition} to position
				set {xSize, ySize} to size
			end tell
			-- modify offsets if hot spot is not centered:
			click at {xPosition + (xSize div 2), yPosition + (ySize div 2)}
		end try
	end tell
end tell

Here is the simpler, faster, more direct way to click the same button:

activate application "AppleScript Utility"
tell application "System Events"
	tell process "AppleScript Utility"
		-- insert GUI Scripting statements here
		click button "Set Up Actions..." of window "AppleScript Utility"
	end tell
end tell

There isn't much documentation available online about GUI Scripting.  
One way to learn about it is to download the 30-day free trial version  
of my application, PreFab UI Browser, from www.prefabsoftware.com/uibrowser 
. The Help menu leads you to lots of documentation. UI Browser's  
AppleScript pop-up menu writes GUI Scripting statements for you based  
on user interface elements you select in UI Browser. I used UI Browser  
to write the above examples.

--

Bill Cheeseman - [log in to unmask]
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com

PreFab Software - www.prefabsoftware.com