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
Hello.
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
Hello.
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.
Hello.
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.
Good Luck!
HTH
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!
Hello.
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.
Hi all,
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
In short, no. I took your code as a basis, because I thought: a person will not tell to a button that System Events does not see.
But I’m interested in experimenting with this scary Pro Tools. I will install it and try for myself.
I don’t know what Pro Tools was like in 2010, but I downloaded the trial version 2019.5.0 from official site to try the application. As I understand it, the post is about the difficulty of choosing tools in the toolbar.
I did not find any difficulty in choosing the tools “Zoomer tool”, “Scrubber tool” and “Pencil tool (Free Hand)”.
The difficulty lies in choosing the Trim tool, Selector tool and Grabber tool. These 3 buttons are hidden behind the button - group “Smart tool” (visible to system). The system sees this group without problems, unlike the buttons located in it. These are the so-called “invisible” buttons for the system, which become “visible” only when you hover over them the mouse pointer.
Below I give an example of scripting “Pro Tools”, which has 2 advantages over previously proposed solutions. 1) the coordinates of the buttons are found by the script itself, 2) third-party software is not used.
use AppleScript version "2.4"
use framework "CoreGraphics"
property |⌘| : a reference to current application
property updateMouseCursorPosition : true
property buttonCount : 1 -- left mouse button number
property mouseButtonDown : true -- mouse button pressed?
set aPoint to |⌘|'s CGPointZero
tell application "Pro Tools" to activate
tell application "System Events" to tell process "Pro Tools"
--window 2 is here window ("Edit:" & name of edited file)
tell window 2 to tell group "Cursor Tool Cluster"
click button "Zoomer tool" -- "Zoomer tool"
delay 1
click button "Scrubber tool" -- "Scrubber tool"
delay 1
click button "Pencil tool (Free Hand)" -- "Pencil tool (Free Hand)"
delay 1
click button "Smart tool" -- "Smart tool"
delay 1
set {x0, y0} to position of button "Smart tool"
end tell
end tell
-- choose "Trim tool" inside "Smart tool"
set aPoint to {x0 + 20, y0 + 20}
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 0.1
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, mouseButtonDown)
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 1
-- choose "Selector tool" inside "Smart tool"
set aPoint to {x0 + 60, y0 + 20}
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 0.1
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, mouseButtonDown)
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 1
-- choose "Grabber tool" inside "Smart tool"
set aPoint to {x0 + 100, y0 + 20}
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 0.1
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, mouseButtonDown)
|⌘|'s CGPostMouseEvent(aPoint, updateMouseCursorPosition, buttonCount, not mouseButtonDown)
delay 5 -- NOTE: this delay 5 and all delay 1 are only for testing purposes
Hi KniazidisR.
The framework you need is “CoreGraphics”, not “AppKit”.
According to the Xcode documentation, CGPostMouseEvent is deprecated as from Mac OS 10.7 and CGEventCreateMouseEvent should be used instead. I haven’t read enough to be able to say whether the latter actually executes the event or merely creates it. AppleScript version “2.4” would be good enough in either case.
It only creates an event, but it doesn’t matter because it requires arguments that ASObjC doesn’t bridge, so it can’t be used from ASObjC.
But how does CGPostMouseEvent works if AppKit is wrong? It works fine. As I understand you, I should use smaller, closest to method framework?
Show how to do the same with CGEventCreateMouseEvent.
I would be very grateful, since I myself have not figured out a new method. How to create event, how to post, how to release. Did I understand correctly that the new method is useless for AppleScriptObjC?
Hi KniazidisR.
It’s possible that you’ve used the “CoreGraphics” framework at some time in the past and that the necessary information’s therefore already loaded into the editor you’re using. I was going to quote from the relevant passage in Shane’s book Everyday AppleScriptObjC, but there’s a footer immediately below it on the page forbidding the whole or partial reproduction of anything in the book without written permission. (I’ve even paraphrased that just to be on the safe side! 
) Basically, he says that once a framework’s been loaded into an application, it stays loaded. So that could be why CoreGraphics methods work in a script run in your editor even when that framework hasn’t been specified in the script itself. Shane urges that the relevant framework be declared in any script which uses its methods. In the case of the methods in your script, that framework is CoreGraphics.
That’s what Shane was saying, yes, which is a pity. 
If CGPostMouseEvent still works at the moment, I suppose you could keep it and perhaps include a comment noting that it’s been deprecated since 10.7. The script might need to be rewritten at some point in the future, but then that often happens with scripts anyway. They need to work at the time they’re written. The future may (or may not) bring about some change or workaround allowing the then current method to be used — or even a change in Pro Tools!
Wow, a bold statement for someone who never used the app in question.
I am scripting Pro Tools since a decade, if not longer, Stefan has helped me so much during all this time. I have learned so much from him. You better listen to him, if you do not respect me.
As far as Pro Tools is concerned, just consider that I know what I am talking about.
I am not making things up, I gave advise to the OP.
If you have other methods and/or solutions to avoid the 6 second delays without using 3rd party solutions -CLIs that is- then I am all ears, I would love to hear about your ideas. Simply because this issue is a real bugger within Pro Tools since ages.
Edit: Name-calling removed by moderator. Please don’t insult other people on these fora.
Nigel,
Consider this written permission
To add to what you said…
When AppleScript sees a use framework statement, it does two things:
It tries to load the framework into the host application. This does nothing if the app has already loaded it.
It loads a .bridgesupport file from the framework, which contains, among other things, the values of any enumerations and details about consts. It can also contain stuff about some methods and functions, although not all of this is used.
If the framework has been loaded by another script already, there’s no problem. But if the framework is already loaded by virtue of being used by the host application, the second point is problematic. In that case, you will find some code works, until you, for example, use an enum.
In cases like this, where GUI scripting is involved, I’d argue there’s no might about it.
Thanks, Shane. Your copyright notice doesn’t specify whose written permission is needed, but I suppose the implication from the context is good enough from a legal standpoint.
Thanks for this too. It’s clarified a couple of things in my own mind.
I am not sure what name calling I may have used but sorry for probably violating the forum rules.