I have used a simple AppleScript that toggles between active and inactive macOS Mail accounts that has worked peachy up until macOS 10.15 Catalina. I generally trigger this through the Script Menu to hide one account and enable another, but have also tried by simply opening and running it. Either way, it's now failing with the error:
Blockquote error "Mail got an error: AppleEvent handler failed." number -10000
Here's the script: what am I missing here to having this work in Catalina?
tell application "Mail"
set enabled of account "Mac" to false
set enabled of account "Windows" to true
end tell
Related
One new feature of macOS 13 Ventura is the new layout and design of the system preferences. However, this caused many of my automation scripts to stop working.
Does anyone know how to navigate through the new system preferences? To be precise, what is the equivalent to the following code which is compatible with macOS 13 Ventura?
tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.sound"
end tell
The code above worked with old versions fine, but shows
execution error: System Settings got an error: AppleEvent handler
failed. (-10000)
in macOS 13 Ventura
I've encountered the same issue, it seems to be a known issue, and it was also discussed at https://gist.github.com/rmcdongit/f66ff91e0dad78d4d6346a75ded4b751?permalink_comment_id=4286384
What you're looking for is:
do shell script "open x-apple.systempreferences:com.apple.Sound-Settings.extension"
However, manipulating that screen is another pickle.
Does it have to be AppleScript or is bash okay? If bash is an option, you can use the open command. To your specific ask, you can use the following to open Sound preferences:
open x-apple.systempreferences:com.apple.Sound-Settings.extension
More details can be found here: https://www.macosadventures.com/2022/12/05/how-to-open-every-section-of-macos-ventura-system-settings/
Previously to the Yosemite update, I used this Applescript to control my Spotify.
Everything worked as a charm when I ran /usr/bin/osascript /Users/jdrummond/SpotifyControl.scpt play/pause.
Now that I have updated my OSX to Yosemite, I keep getting this when I run the same command:
/Users/jdrummond/SpotifyControl2.scpt:1217:1222: script error: Expected end of line, etc. but found identifier. (-2741)
So I tried to create a simple Applescript to interact with Spotify:
using terms from application "Spotify"
tell application "Spotify" to play
end using terms from
But I'm also getting an error:
What am I doing wrong and how to interact with Spotify on Yosemite? Anything changed?
This issue was reported to Spotify and will be fixed in the next update to the desktop client (I'm a developer there and can verify that it has been fixed).
Currently, the following simple script is working for me on OS X 10.9.5, Spotify 1.0.3.101.gbfa97dfe
tell application "Spotify"
playpause
end tell
I saved it as an app in other to use with my Microsoft Keyboard, so that the play/pause button launches the simple app that plays/pauses.
Spotify destroyed the ability to use AppleScript very recently with their latest idiotic update. It's not Yosemite, it's Spotify.
I have a Mac app store app that just silently disappears when it crashes. It doesn't show the CrashReporter dialog to give the user a chance to report the crash to Apple.
I see the same behavior on multiple machines. Is there any known reason why this might happen?
According to TN2123:
In addition, if the program that crashed is running as a logged in GUI
user, CrashReporter will present the user with a dialog asking them
whether they want to submit a bug report to Apple
What does "running as a logged in GUI user" mean? Does a window have to be visible?
Update:
I was reading the manpage for ReportCrash, and found the following:
For application crashes (but not background process crashes)
ReportCrash will display a dialog notifying the user that the
application unexpectedly quit and offering to reopen the application
or send the report to Apple. For developers, the behavior of this
dialog can be adjusted using
/Developer/Applications/Utilities/CrashReporterPrefs.app which is
installed as part of the developer tools.
I ran CrashReporterPrefs and changed my CrashReporter mode to Developer. When I ran the app and triggered the crash, the CrashReporter dialog was shown!
So I guess the question now is: What's the difference between an "application" crash and a "background process" crash?
If your app uses LSUIElement or LSBackgroundOnly, it's a “background process” for the purpose of determining whether to show the Crash Reporter. (Other “background processes” include UNIX-land daemons, such as the Apache web server, and processes started from SSH or telnet connections.)
Since CrashReporterPrefs no longer comes with developer tools, you can change the behavior to show the dialog for daemons by running this command in the Terminal:
defaults write com.apple.CrashReporter DialogType Developer
I have a problem with AppleScript and System Events.
I have check "Enable access for assistive devices" in the “Universal Access” preference pane in System Preferences.
When I try :
arch -i386 osascript -e 'tell application "System Events" to get the position of every window of every process'
I have this error :
System Events got an error: Access for assistive devices is disabled. (-25211)
Do you have any idea ?
Thanks a lot
On Mac OS X 10.9 you actually get the same error when the AppleScript Editor is not allowed to use Accessibility.
Here's how you enable it:
Go to System Preferences > Security & Privacy > Privacy > Accessibility.
Then, just check the checkbox left to the AppleScript Editor and the error should be gone.
The problem is not the assistive devices. AppleScript seems to incorrectly return that error code when it tries to access windows of a process that can never have any windows (in my case it was "Google Chrome Helper").
You need to catch the errors. This works for me:
tell application "System Events"
set procs to processes
set windowPositions to {}
repeat with proc in procs
try
if exists (window 1 of proc) then
repeat with w in windows of proc
copy w's position to the end of windowPositions
end repeat
end if
end try -- ignore errors
end repeat
end tell
return windowPositions
returning a list of coordinate pairs, such as {{1067, 22}, {31, 466}, {27, 56}, {63, 22}, {987, 22}} – is that what you were trying to get?
Similar to the post on this page about Mac OS X 10.9 (Mavericks), to resolve this issue on Mac OS X 10.8 (and likely on earlier versions of OS X also), you need to ensure that the "Enable access for assistive devices" option has been enabled in the Accessibility pane of System Preferences.
In OS X Lion apps automatically resume when the user logs in. My app is set to be a windowless agent without an icon in the Dock (LSUIElement is set to YES in Info.plist) and it doesn't resume when I restart my machine.
According to Apple documentation all applications get the Resume behaviour by default and the developer doesn't need to do anything special to enable it. Are LSUIElement apps a special case? Is there anything that needs to be done to enable them to Resume?
From my own testing, LSUIElement applications are not resumed. So yes, they appear to be a special case – you'd need to ask Apple why this is the case, but setting this value appears to forcibly disable resume.