Long Script Runtime

Scripting Forums AppleScript | Mac OS X
,
#21

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.

#22

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
#23

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.

#24

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.

#25

  1. But how does CGPostMouseEvent works if AppKit is wrong? It works fine. As I understand you, I should use smaller, closest to method framework?

  2. 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?

#26

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! :wink: ) 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. :frowning: 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!

#27

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.
:slight_smile:

Edit: Name-calling removed by moderator. Please don’t insult other people on these fora.

#28

Nigel,

Consider this written permission :slight_smile:

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. :wink:

#29

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. :wink:

Thanks for this too. It’s clarified a couple of things in my own mind.

#30

I am not sure what name calling I may have used but sorry for probably violating the forum rules.