Here's a very strange problem. I have a macro that works consistently (for a number of years) on both an Intel iMac and an MacBook M1. However, it does not work on a MacBook Pro Intel, where it quickly switches to the next space and then immediately snaps back. I've tried AppleScript and typing a key. And before you ask, yes, the key is defined correctly in the Mission Control Keyboard Shortcuts setting and all Macs are running the same OS version, Sonoma 14.2.1.
Oh, the script works on its own, to be clear. Not much to go wrong. It’s the side effects that are the problem. The other Macs don’t have the same side effects.
Right, but I was asking does it snap back if run from Script Editor? (Trying to determine if this is a KM issue, or something about the keyboard shortcuts on that Mac.)
On the Mac that fails, If I do NOT run this macro, it doesn’t snap back. If I do, it DOES snap back. On other Macs, I can always run this with impunity.
This macro changes the state of the Finder or Mission Control in some weird way, but is the only way I know to hide icons on the desktop.
And again, it works on all Macs except the one I mentioned.
It's really hard to tell, since the system is a lot of macros, some shell scripts, some applescripts. I cannot just run the whole thing in script editor.
I've narrowed it down to the single macro I showed earlier. If I run it, it snaps back. If I don't run it, it doesn't. And it only happens on one Mac, not all of them. It's not KM.
Just wildly guessing, I'd think the macro does what it should (if it does on other Macs and even the script works on the concerned Mac), so may there be something else pulling things back? Another macro or script maybe, or just an app trying to come (back) to foreground (and the space changing back to show that app)?
I expect that your 5 machines are not perfectly synchronised in every aspect, so they may run different things.
Did you try to quit as many applications on the concerned Mac as possible while trying the macro? Maybe deactivate the system preference to change space to open windows when changing apps? Are there any other apps using spaces or customizing the user interface that might interfere? You mentioned, this script is part of a bigger construction... maybe there are other macros to change spaces that activate from this macros action? Try to run it as isolated as possible and if it runs, one of the things you shut down must be the problem.
If your script/macro works on your other machines, it seems to have some kind of problem with its environment, but since this is a huge variable, we have to narrow down the problem... as I said, this is just a very general approach, sorry, but the only one that comes to my mind, that might help.
I’m sure you’re correct: clearly something is different. But I’ve checked the settings as far as I can, manually: system settings, finder settings, etc. I don’t want to have to quit running apps just to run my screensaver in case you’re wondering. Screensaver runs asynchronously, but I haven’t found any concurrently problems.
To reiterate: 4 out of 5 Macs, all running the same version of the OS (14.1.2) work fine. Only one does not, and it’s not the oldest nor the newest nor the slowest nor the fastest.
The only way you'll solve this, I think, is with some systemic testing. If I were having the problem, I'd create a new user account on the troublesome Mac, install Keyboard Maestro and the macro, and see what happens. This eliminates all third-party app interference and lets you test in a clean environment.
If it works there, which I assume it will, then you know you have something different with the main account. And at that point, it becomes tedium to find the problem. Quit all running apps, test macro again. Quit all third-party always-running utilities and test again. Etc. Eventually you'll find a config that works. Start adding stuff back until it breaks again.
It's definitely not fun, and ridiculously time consuming, but you've eliminated all the simple explanations, so the only thing that's left seems to be interference from another app or third-party utility, or some OS-level setting somewhere.
Only you can decide if it's worth this time investment, obviously.
Thanks. This occurred to me also. I did a quick experiment since I had an “admin” backstop account, but setting it up was taking it too long - Dropbox, etc.
Reminder: this problem exists on only ONE of 5 Macs I have.
I’ve traced the problem to an interaction between two macsos:
the code to hide icons on the desktop.
The code to hide applications.
The code to hide icons requires the Finder, and then Forcing it to quit and restart.
The code to hide all applications is very sensitive, using a combination of Finder-> Hide Finder, Finder-> Hide Others, an AppleScript I wrote to set all non-Finder windows to be not visible, and KM’s hide all applications in both flavors: those on the excluded list and the rest.
If I DON’T hide icons on the desktop, it all works fine on the particular Mac in question. However, if I DO, even though I’ve hidden all the app windows, the Finder keeps bringing one or more of them back for some unknown reason.
I wish there were a simple way to hide all Finder windows and non-Finder windows AND KEEP THEM HIDDEN.
The problem seems related to Finder interactions with the shell code to hide/show desktop icons. So, don't do it that way. Use Systems Settings instead.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
-- https://www.youtube.com/watch?v=MOdIFEU1WV8
tell application "System Settings"
delay 1
-- get properties
reveal pane id "com.apple.Desktop-Settings.extension"
tell pane id "com.apple.Desktop-Settings.extension"
reveal anchor "Desktop"
end tell
end tell
tell application "System Events"
-- activate
tell application process "System Settings"
repeat while (get name of window 1) ≠ "Desktop & Dock"
delay 0.1
end repeat
-- Desktop & Dock
tell window "Desktop & Dock"
-- discovery only
-- get entire contents
tell scroll area 1 of group 1 of list 2 of splitter group 1 of list 1
tell group 4
-- set showIcons to value of checkbox "Show Items" as boolean
-- if showIcons then click checkbox "Show Items"
click checkbox "Show Items"
delay 0.5
end tell
end tell
end tell
end tell
end tell
I have finally figured out what caused my problem, and I'd like to share this educational experience. It turns out that when one disables a macro, it still can be called with an execute macro operation. In other words, it's not really disabled!. When one disables a macro, its triggers are disabled, not the macro itself. I didn't know this.
