I am on KM 9.0.5 (on Mojave 10.14.6), and I just ran into this same problem. Having a simple "copy" action in a macro timed out. (Specifics: I am tried to create a macro that copies text I selected in a metadata field in Adobe Lightroom.)
Copying plain text should be very fast. I do that often with KM, and it works well.
Does a manual copy (with the Edit > Copy, or ⌘C) work OK? If so, then likely there is something wrong with your Macro design.
Yes, the regular system copy (with the Edit > Copy, or ⌘C) works fine. I created the simplest macro — just the Copy action, and tried it in a number of applications (including "Stickies"), and get the same timeout error each time. Here's the macro and the error:
What this means is that Keyboard Maestro simulated the Command-C key, and then the clipboard did not change.
If this happens in multiple applications, then perhaps Keyboard Maestro cannot simulate any keys, which would point to an accessibility problem likely resolved by toggling the accessibility permissions in the System Preferences as described at: Accessibility Permission Problem assistance.
Without the step that executes pbpaste and stores it in clipboard, no matter what I did, Copy did not work in the multiple applications that I tried (TextEdit, BBEdit, Excel, Notes).
I had been struggling with this issue of Copy (either the Copy action or by simulating Command-C key) not working for a couple of hours since today morning. The macro in question was last used 3 weeks ago, so I am not sure what happened during this time to cause this. I am on Catalina (10.15.7) with KM Version 9.2.
Initially, I thought that this might be due to an update I recently installed in MS Excel so tried using the apple script posted here: https://forum.keyboardmaestro.com/t/system-clipboard-not-getting-replaced/15188/9 to no avail. However, this was a red herring as I soon discovered that Copy (function or simulated keystroke) did not work in other applications as well.
I had followed the steps suggested for fixing Accessibility issues (TIP: Resolving Catalina/Mojave Accessibility/Security Permissions Issues), but they did not help. However, I soon discovered that simulating keystrokes was definitely working since I was able to get KM to simulate typing characters inside the problematic applications. Even for Excel, on simulating Command-C, the selection would change to a dotted box to prove that Command-C had indeed been successfully simulated.
Adding delays after the Command-C did not help.
Also tried killing pboard process to make sure this was not a case of the clipboard process having issues. Restarted MacOS just to tick off that old chestnut.
Hope this helps!
@JMichaelTX : My apologies for bringing this to your attention, but do you think that this might be worth adding as a workaround to the official documentation or as a note to the wiki?
This is basically impossible – so why is the impossible happening on your system? These kinds of things don't occur in a vacuum.
A) Do not simulate Cmd-C unless it's the only option available. There are too many things that can go wrong with simulated keystrokes. Use the Copy action or the Select or Show a Menu Item action to select the menu item Edit › Copy.
B) Bring up the Clipboard History Switcher and see what's in the History. Copy 3-4 things to it in the normal fashion, and make sure it's working correctly.
C) Do you have any other apps or utilities that use or might interfere with the clipboard?
D) Do you have any other apps or utilities that use or might interfere with the Cmd-C keystroke?
E) Does the problem occur when you boot your system in safe-mode?
F) If you create a clean new user and install only Keyboard Maestro, does the problem still occur?
I tried the Troubleshooting instructions, and found things in KM that I never knew existed (which I guess is a testament to how well KM works as I've never had to debug an issue with a macro before). The Help Wizard did not reveal anything wrong with the Macro (which is a test macro with a step to copy something in different ways and a subsequent step to display the system clipboard).
The Clipboard History Switcher was much more interesting. I discovered that I could not activate the history switcher at all and then from another thread (Activate Clipboard History Switcher : Long delay) there was advice to do this :
And then everything started working. This still leaves the question of 'why now / what changed to cause this' unanswered, but I am happy to have things working now without hacks.
I have never used KM as a Clipboard manager before today, so am not sure what effect the above command had to fix the issue.
I just want to clarify that this is the desired, and expected behavior.
The KM Copy Action attempts to copy the selected object.
If that Action times-out, that means that either there was NO selection, OR, the selection was so large that it could not be copied within the timeout of the Copy Action.
This should be a rare event. However sometimes the User has NOT selected anything.
Thus, instead of terminating the macro (the default behavior), you can check the success of the prior action, and if it fails, then take some specific action.
In one of my Macros, if the Copy Action fails, then I select the text from the current insertion point to the end of the line, and then copy that.
If you haven't used a clipboard-history utility on the Mac before, you've missed out on very useful functionality.
I totally agree with the usefulness of a clipboard manager. I do not use KM's clipboard manager since I prefer 'CopyQ' (open source, cross-platform) to reduce the jarring context switch between Windows and Mac when I am forced to use the former.
If I were to use Windows only, I would prefer 'Ditto' since its performance is much better than CopyQ (for instance when searching for regex).
If you've used CopyQ, I would be very interested to know how it compares to KM's clipboard manager.
@peternlewis, can you confirm or refute that setting the KM Clipboard History to zero may cause problems? If so, can you please describe these problems?
Set the clipboard history to 0 simply means that Keyboard Maestro will not read the system clipboard when it changes - instead it will read it only when you perform an action that explicitly reads it (eg using the SystemClipboard token, or an action that has the system clipboard as an input).
However, if you set the Clipboard History size to zero, or you exclude an application from Keyboard Maestro’s clipboard history, then the Copy action will fail because it simulates a Command-C and waits for the clipboard to change, and the clipboard will not change because Keyboard Maestro will not read the clipboard.
It could be argued either way as to whether this is a bug in the Copy action or Keyboard Maestro behaving exactly as you have explicitly told it to. I'd probably lean towards the former, but this situation only happens if you explicitly tell Keyboard Maestro not to read the clipboard. You can use Command-C instead, since that is all the Copy action does - perform Command-C and wait for a clipboard change.
I will ponder whether to the behaviour of the action should change.
