I can not figure out why this script takes so long to run. It pulls the window (click button 1 of tool bar 9 of window 1) up the instant I run it but takes six seconds to actually get to the next part of the script to key code ‘enter’. I know I can just run the script and then press enter quickly and remove the key code from the script but any ideas why it might take so long for the script to move to the next part or how I can work around this?
activate application "Pro Tools"
tell application "System Events"
tell process "Pro Tools"
click button 1 of tool bar 9 of window 1
tell application "System Events" to key code 76 -- Enter
end tell
end tell
This of course won’t work either because it presses the key command before the window opens. I can’t stick a delay anywhere so I am stuck!
activate application "Pro Tools"
tell application "System Events"
tell process "Pro Tools"
tell application "System Events" to key code 76 -- Enter
click button 1 of tool bar 9 of window 1
end tell
end tell
Browser: Safari 536.29.13
Operating System: Mac OS X (10.8)
I speculate wildly, that your AppleEvents are pending for some reasons unknown.
Please try the version below, and I hope it helps!
activate application "Pro Tools"
tell application "System Events"
tell application process "Pro Tools"
click button 1 of tool bar 9 of window 1
end tell
set nm to name of application process whose frontmost is true and visible is true
tell application process nm
key code 76 -- Enter
end tell
end tell
Thanks for the post it still takes six seconds and errors on “Can’t get name of application process.”
This seems really strange since Pro Tools is in the foreground and I can see it activate.
Running Script Debugger in debugging with trace it is definitely “click button 1 of tool bar 9 of window 1” that takes the bulk of the time at just over 5 seconds of the six seconds to run. So strange since again the window pops up instantly, it is like it is looking for something beyond the time it took to already find the button to click.
there’s another way to perform a click
As “System Events” is currently told the explicit tell in the key code line is not needed
activate application "Pro Tools"
tell application "System Events"
tell process "Pro Tools"
perform action "AXPress" of button 1 of tool bar 9 of window 1
key code 76 -- Enter
end tell
end tell
Pro Tools not being all that accessible, just strange that it pops up the window so fast.
Thanks for the idea and help, I wish that it had worked, this is so wacky.
I can think of one more thing to try; to split it up in two System Event’s calls, with an activation of say SystemUIServer in betweeen, before activating ProTool again, and performing the last System Event’s block, that performs keycode 76.
(I wonder if keycode works when just used on its own with Pro Tool as well.)
If the “click button” event itself is the bottleneck, then there is no way in the GUI script to get rid of the delay.
The only way to dispatch events asynchronously in AppleScript is to save parts as application and call them from the main script as a different process (aka thread).
But I’m not sure that this works also in GUI scripts
omething like this? I tried a few other variations of this. I just realized in the event log it is returning “missing value” for “click button 1 of tool bar 9 of window 1” even though it is clearly clicking that button.
activate application "Pro Tools"
tell application "System Events"
tell process "Pro Tools"
click button 1 of tool bar 9 of window 1
tell application "SystemUIServer"
tell application "System Events"
tell process "Pro Tools"
tell application "System Events" to key code 76 -- Enter
end tell
end tell
end tell
end tell
end tell
I even tried breaking the script into two scripts and then running a third scirpt to call the two scripts but the second script that presses the enter key will not process until the first script processes.
run script alias ((path to home folder as text) & "Desktop:Click Pro Tools Box.scpt")
run script alias ((path to home folder as text) & "Desktop:Press Enter in Pro Tools Using System Events.scpt")
Hi Stefan,
I just saw your post after I posted just after you. Is the last AppleScript I did by calling the two scripts from a third script what you were talking about, or is there another method I am not aware of?
Well darn it looks like it isn’t going to work. I compiled my first AppleScript in the thread as an app and that didn’t work.
Than compiled the two separate scripts into apps and ran this as a script and as an app and nothing worked. Thanks for all the help in trying to get this to work.
tell application "Click on Pro Tools Box" to launch
tell application "Press Enter in Pro Tools Using System Events" to launch
I meant just, or something like it, as few levels nested as possible. The objective was to try and “short-circuit” the event queue of Pro Tool, making it start afresh so to speak. I am not sure if this conflicts with Stefan’s say about multiple threads, but I don’t question anything he has to say about it. If he means the effect can possibly be achieved by executing two apps from a script, to do it, then I’d try just that!
” first applet...
tell application "Pro Tool" to activate
tell application "System Events"
tell application process "Pro Tool" to click button 1 of tool bar 9 of window 1
end tell
” second applet...
tell application "SystemUIServer" to activate
tell application "Pro Tool" to activate
tell application "System Events"
tell application process "Pro Tool" to key code 76
-- ”
end tell
You mustn’t launch, you must activate or even better, have handlers inside both applets, that you tell the applets to do:) tell MyApplet to doTheDishes()"
I meant just, or something like it, as few levels nested as possible. The objective was to try and “short-circuit” the event queue of Pro Tool, making it start afresh so to speak. I am not sure if this conflicts with Stefan’s say about multiple threads, but I don’t question anything he has to say about it. If he means the effect can possibly be achieved by executing two apps from a script, to do it, then I’d try just that!
” first applet...
tell application "Pro Tool" to activate
tell application "System Events"
tell application process "Pro Tool" to click button 1 of tool bar 9 of window 1
end tell
” second applet...
tell application "SystemUIServer" to activate
tell application "Pro Tool" to activate
tell application "System Events"
tell application process "Pro Tool" to key code 76
-- ”
end tell
I actually did the activate first and then tried launch in desperation thinking that pulling things to the front might be what is making it wait.
-- first applet.
tell application "Pro Tools" to activate
tell application "System Events"
tell process "Pro Tools"
click button 1 of tool bar 9 of window 1
end tell
end tell
-- second applet.
tell application "SystemUIServer" to activate
tell application "Pro Tools" to activate
tell application "System Events"
tell application process "Pro Tools" to key code 76
-- ”
end tell
Well shoot that did work either, good to know I have exhausted the possibilities.
It is interesting that I have to change
tell application process "Pro Tool" to click button 1 of tool bar 9 of window 1
To
tell process "Pro Tools"
click button 1 of tool bar 9 of window 1
end tell
in order to work. Also thanks for the tip on “tell application “SystemUIServer” to activate”
that looks like it might come in handy in the future.
Maybe you hoped every possibility was exhausted, I just stick around a little bit longer in this thread.
Have you heard about cliclick? It is a command line tool that performs mouse actions, also in combination with modifier keys in a do shell script. There is also a utility called MouseLocation That reports the position of the mouse. Given those two tools, and with the hope that you at least can get the position of the window, you should be able to figure out/calculate where to put clicks. You can use sleep in do shell scripts, as an alternative to delay in Applescript too, should you need to wait for something in the process.
P.S. When I want find some coordinates, I tend to cheat for starters, and I use the shift-command-4 for screencapture, and mouse around getting coordinates, before I finally hit escape. D.S.
Thanks McUsrII, I had been using MouseToolsTools http://www.hamsoftengineering.com/codeSharing/MouseTools/MouseTools.html with varying degrees of success, I ended up giving up on it since it seem so intermittent in working for some reason. I ended up using AppleScript to trigger an action in QuicKeys for mouse clicks for things I do but CLICLICK looks to be a solution I couldn’t find before in my google searching. Thanks again for all the suggestions!
The windows change in Pro Tools in where you click all the time because you can expand the side windows which moves where this pop up would be so my difficulty in trying that (I have spent many hours trying that approach). So glad you told me about those utilities though they will come in handy!
It is easy to give advice when I don’t actually have to do something!
Joke aside, I noted what you said about the varying size of the sidebar, but unless that sidebar is anything like a coverflow window, you should be able to go in with ui scripting, and get the full size of the window, and of panes/splitter groups or whatever, and be able to calculate the offset correctly.
A little trick I have used, to be sure that the window is focused, is to set focused of something in the window (With UIScripting) , that tend to make the whole script less “flaky”, as a user seldom will manage to interfere, while you are processing. (Should he / she, then they would have to react within a fraction of a sec, when you intersperse your script with “set focused lines”).
Edit
The best thing is, if you can figure out a position of an element: button or other clickable thing, that always has the same relative position to something else. LIke the ok button ends always 20 pixel above, and 20 pixels to the right of lower right corner of the window. Then you can use the same formulae all the time, for calculating the middle of the ok button, if the ok button has a static size.
I just stumbled across this thread.
This infamous 6 seconds delay is a known issue when scripting the Pro Tools GUI. Use cliclick instead and click the button or menu item by it’s position. Works flawlessly!
Actually, it’s not clear what advantage Clickclick can give here over an ordinary click from System Events. And since this is from third-party developers, System Events should be preferred. Here StefanK has already provided the desired code. I add click stability to it in a simple way:
tell application "Pro Tools" to activate
tell application "System Events" to tell process "Pro Tools"
repeat until (button 1 of toolbar 9 of window 1 exists)
delay 0.1
end repeat
perform action "AXPress" of button 1 of toolbar 9 of window 1
key code 76 -- Enter
end tell
Another is this: if you still prefer to click with the Clickclick, you do not need to search for the coordinates of the button manually and hardcode them in the script. It is enough to ask the button itself about its coordinates on the screen (its property position).
Do you know Pro Tools? Have you ever scripted Pro Tools?
Apparently not otherwise you would know that Pro Tools uses a lot of custom UI elements which are not based on Cocoa and therefore are not accessible with standard GUI scripting.
cliclick (which performs a mouse click on a specific screen coordinate) is often the only way to GUI script Pro Tools and is much faster than sending Apple Events via System Events
