Le 03/01/2014 à 14:55, Bill Cheeseman <
email@hidden> a écrit :
On Jan 2, 2014, at 12:04 PM, koenig.yvan <
email@hidden> wrote:
I was really puzzled when I discovered that the standard instruction click at {x, y} failed with :
I was told a very long time ago, by the Apple engineer who originally wrote the System Events Processes Suite code, that the 'click at' command first determines what UI element is at the given location, and then sends the 'click' command to that UI element. That seemed an odd choice to me at the time, because the only reason I ever had to use 'click at' was when 'click' on a specific UI element wouldn't work for some reason. I would rather have seen 'click at' send a 'click' to the given location, so I could use it as an alternative technique when clicking the UI element didn't work. As it was written, however, 'click at' always failed if 'click' failed.
I don't know whether the underlying code has changed since then, and I don't know whether this information sheds any light on the behaviors you are seeing. But it does suggest some additional lines of testing.
Hello
Axel Lütgens just wrote (and he is right) that if :
tell application "TextEdit" to activate
tell application "System Events"
tell application process "TextEdit"
keystroke "p" using {command down}
delay 1
set {x, y} to position of first menu button of sheet 1 of window 1
click at {x, y}
end tell
end tell
fails,
tell application "TextEdit" to activate
tell application "System Events"
tell application process "TextEdit"
keystroke "p" using {command down}
delay 1
click at position of first menu button of sheet 1 of window 1
end tell
end tell
behaves flawlessly.
So I continued my tests and compared what I get wit a button (or a menu button) to what I get with a menu item.
tell application "TextEdit" to activate
tell application "System Events"
tell application process "TextEdit"
keystroke "p" using {command down}
delay 1
position of first menu button of sheet 1 of window 1
--> {1500, 663}
click at result
--> error number -1700 from {1500, 663} to list
end tell
end tell
The grabbed position is a global value as the one returned by Accessibility Inspector.
tell application "TextEdit" to activate
tell application "System Events" to tell (first process whose frontmost is true) to tell menu bar 1
set {mt, mi} to {5, 4}
get name of menu bar items
--> {"Apple", "TextEdit", "Fichier", "Édition", "Format", "Présentation", "Fenêtre", "Aide"}
get name of menu bar item mt
--> "Format"
tell menu bar item mt to tell menu 1
# click it
get name of menu items
--> {"Police", "Texte", missing value, "Convertir au format RTF", "Empêcher les modifications", "Adapter à la page", "Permettre la césure", "Présentation verticale", missing value, "Liste…", "Tableau…"}
get name of menu item mi
--> "Convertir au format RTF"
position of menu item mi
--> {0, 54} if click it is commented
--> {252, 76} if click it is uncommented
click at result
--> error number -1700 from {0, 54} to list if click it is commented
--> error number -1700 from {252, 76} to list if click it is uncommented
--click menu item mi
end tell -- menu bar…
end tell
In this case I may understand that clicking at result fails because the menu is not scrolled.
This time, I grab the position of a menu item and its position is not global, it's local in the hosting menu.
I never took care of that and just discovered that I must uncomment the click it instruction to get global position which is returned by Accessibility Monitor
The lesson of these tests is that it's bad idea to try to trigger an UI item with click at position_in_a_variable.
click at position of the_UI_item may be OK
but click the_UI_item is better which seemingly works in every cases.
Yvan KOENIG (VALLAURIS, France) vendredi 3 janvier 2014 16:33:18