Many (or most) macOS applications generate a system alert sound (or beep) when a keystroke is pressed that the application is not able to accept. For example, if I press a function key when Notes is running and frontmost, I get the beep.
Why doesn't the KM "Type a Keystroke" action generate an error condition when we can hear the error beep? If it did, I could handle those error conditions gracefully. For example, I could write this: (which would keep pressing the key until the key was accepted)
Also, the "Find Image" action has a "Wait for Image" option on the cogwheel. Perhaps the Type a Keystroke action could have a "Wait for Key Acceptance" in the same way. (I.e., the Type a Keystroke action would repeatedly press the key until no error was returned.)
Hopefully Peter will reply, but I think the problem is that the receiving application doesn't communicate back to Keyboard Maestro what happened when the key was pressed. So there's no way to add error detection, because no errors are being sent back. To Keyboard Maestro, it looks like the key press worked.
If I may take a guess until an authoritative answer arrives..! The absence of a beep indicates that MacOS can tell the difference between a real keystroke and a simulated one, so I should think it is a question of how MacOS decides to handle that—an Apple API issue again.
I suppose if that were vitally important, it might it be wiser to, if possible, check the state of the target application (e.g. by verifying which menu items are available).
My reply overlapped... I think we are of like mind in expecting that Apple would not have made a special effort to provide a public API method of providing such feedback!
The two of you guys are probably right, but I found it perplexing that macOS was generating an error sound and that KM is not able to tap into that to determine if there was an error or not.
My guess is that, in this case, it's not a true error sound that has a related error number that would be logged in Console and visible. I think it's just a sound designed to let the user know they're trying to type somewhere typing isn't allowed.
But understanding why requires some knowledge, knowledge that can be beneficial in having a deeper understanding of the way things work.
When UI events happen (press key, move or click mouse, etc), including when Keyboard Maestro simulates them, they are placed in the event queue which is a system wide queue. A big part of what an application does is run a loop that extracts the next event from that queue and handle it.
So the application asks the system for the next event, and the system looks at the event and decides what to do - maybe the event is a keystrokes and so the system checks if it is a registered hot key, and if so that is handled in one way, or its a key press so the system goes through a complicated process checking whether the key is a menu shortcut matching an enabled menu, or something that the window can handle, which in turn looks at something the focused item or its parents can handle.
If nothing can be found to handle the key, then the system might decide to make a beep alert noice.
This is also why it's impossible to safely do things like capture a key and then decide to allow it to be handled as a normal key, because the only way to do that would be to put it in the event queue, which might then be out of order if other events are already in the event queue.
It's also a typical source of issues needing a Pause because the event queue means that events that are simulated will be handled when the application is ready to handle them, but if you change the focus (activate an application, close or open a window, etc), then the event might go to the new focus when you are expecting it to go to the old focus location.
Peter's answer is just another example of what a unicorn he is. He explains a complicated process in a simplified way, that ordinary people can understand. And yet he's a programming god. You almost never see those skill sets in one person.
What's the difference between a keystroke and a key press? (The question sounds a setup in another standup routine, and indeed there are some inadvertently funny answers out there...).
Impossible for the OS, I take it.
I wonder whether that is a consequence of Apple not implementing an alternative to the event queue, or whether an alternative would be infeasible... but that subject may be too deep and too irrelevant to the discussion.
Riiight... because the event is available to whichever application finds it first.
I don't know why you would feel bad about it. It was an interesting question and we have an answer "on file" now! Along with my incorrect guess (which I can live with ).
Well, technically, a "keystroke" usually refers to a "keydown" ("key press") followed by a "keyup" ("key release"). With key combinations, like Cmd-Q or Shift-anything, there's multiple keydowns and keyups. The difference is a modifier key (Cmd, Shift, etc.) doesn't usually trigger an action, so until a non-modifier key is pressed, nothing happens. Usually.
Regarding event queues, that's just the standard way most applications and OSes work. There's exceptions, but it's the way things are done. I'm sure Rob could list a ton of exceptions, in fact, but the point is, that's usually the way it is.
Not quite - it's whichever application has the "focus".
He's hillarious - be sure to check out his other videos.
The absence of a beep indicates that MacOS can tell the difference between a real keystroke and a simulated one, so I should think it is a question of how MacOS decides to handle that—an Apple API issue again.
What's the difference between a keystroke and a key press? (The question sounds a setup in another standup routine, and indeed there are some inadvertently funny 