My second monitor is located to the left of my main monitor. So, to click on my second monitor, I simply use a minus sign to designate the x coordinate. Like this: tell application "System Events" click at {-100, 300} end tell Bill Cheeseman

Here are some AppleScript-oriented websites and technotes (mostly quite old): https://www.macscripter.net http://www.macosxautomation.com https://dougscripts.com/itunes/index.php https://computers.tutsplus.com/tutorials/the-ultimate-beginners-guide-to-applescript--mac-3436 https://developer.apple.com/library/archive/technotes/tn2002/tn2106.html https://developer.apple.com/library/archive/technotes/tn2065/_index.html https://developer.apple.com/library/archive/technotes/tn1164/_index.html

System Settings is the name of the application that used to be known as System Preferences. In macOS Ventura, you open System Settings by choosing the "System Settings..."menu item near the top of the Apple menu, at the left end of the standard menu bar. When you oopen System Settings that way, its window always has a sidebar containing the items that used to be shown as preference pane icons. They are listed, not grouped by named categories as they used to be. And some things that I think used to be shown as preference panes now appear instead as items in the main window when General is selected in the sidebar.

I've been working on this. System Settings on Ventura is not scriptable, at least for now, so you must use GUI Scripting. Here is what I have working so far in my Project: activate application "System Settings" tell application "System Events" tell process "System Settings" delay 1 tell splitter group 1 of group 1 of window 1 tell group 1 -- sidebar tell outline 1 of scroll area 1 set rowCount to count of rows repeat with rowNum from 2 to rowCount - 1 if (exists static text 1 of UI element 1 of row rowNum) then if value of static text 1 of UI element 1 of row rowNum is "General" then select row rowNum exit repeat end if end if end repeat end tell end tell delay 1 tell group 2 -- window pane tell group 1 of scroll area 1 of group 1 -- top click button 2 end tell end tell end tell end tell end tell

Accessibility Inspector 5.0 (112) is working fine in Xcode 13.3.1 running on my M1 iMac under macOS 12.3.1. I do have to turn it on frequently by clicking its activation button, and I had to set it up to show advanced element values the first time. My similar UI Browser application is still working fine, too. https://pfiddlesoft.com/uibrowser

The Accessiblity authorization in the Privacy tab of the Security & Privacy pane of System Preferences thinks that an AppleScript applet has turned into a new and different application every time you edit, recompile and re-save the applet. Your Mac therefore thinks the revised applet is unauthorized and refuses to run it. You can quickly and easily solve this problem by unchecking and re-checking the applet's checkbox in the Accessibility authorization. The applet will then run correctly when you double-click it. Here's a simple script to test this: activate application "Finder" tell application "System Events" tell process "Finder" click menu item 1 of menu 1 of menu bar item "Apple" of menu bar 1 end tell end tell

Beta 9 installed over Beta 8 still exhibits this problem for me.

That has been my conclusion. I first released my UI Browser application to explore the accessibility structure in 2002, and it has used the old API ever since. See https://pfiddlesoft.com/uibrowser.

Yes, I have explored Apple's Books application in depth with UI Browser. If you give it a try as I suggested, use UI Browser's browser view to traverse the Books UI element hierarchy down through several levels of "AXGroup" elements until you come to the "AXWebArea" element. Then look in UI Browser's Attributes drawer to see the details of how Books uses Apple's specialized AXWebArea accessibility API to parse text. AXWebArea is a very complex API, and it is not easy to use with GUI Scripting or code. UI Browser can track the attributes and help you write GUI Scripting scripts that will retrieve the text values, but UI Browser is not designed to retrieve AXWebArea text values directly. Apple's Accessibility Inspector utility does retrieve the text values directly.

Apple's Books application is known to contain some "mismatch" errors in its implementation of accessibililty. That means it portrays the UI element hierarchy differently in one direction (for example, in a screen reader that starts with a leaf element on the screen) than in the other direction (for example, in a browser that starts with the application UI element. Try the free trial of my UI Browser application to explore this possibility. https://pfiddlesoft.com/uibrowser

You can download the 30-day free trial of my UI Browser application here: https://pfiddlesoft.com/uibrowser/index.htmlA free alternative is Apple's Accessibility Inspector application, included in Xcode. But it is much harder to use and does not provide AppleScript indexes or, in some cases, specialized AppleScript terminology.You can also write scripts that explore the parent and children of each element in the path, one by one, but that is very time consuming.

GUI Scripting is inherently sensitive to changes in application interfaces from version to version. In your case, the Built-in Retina Display window in System Preferences lost the "group 1" UI Element in macOS Catalina 10.15.4. So you should be able to fix the problem by changing the 'set value' line of your script to 'value indicator 1 of slider 1 of tab group 1'. I have not tested this, but my UI Browser application shows this to be the new element path.