I have used KM Copy Action with all of those and it works well.
Running Keyboard Maestro 9.2 on macOS 10.14.6 (Mojave).
If it is not working for you, that means that something is interfering with KM on your Mac.
Please read Troubleshooting -- KM Wiki.
Hey @azorpheunt,
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?
-Chris
Thank you very much for your wisdom @JMichaelTX and @ccstone
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 :
defaults write com.stairways.keyboardmaestro.engine MaxClipboardHistory -int 20
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.
HTH.
Apparently at some time either you or some macro you ran set the clipboard history to zero, and that fouls things up more than meets the eye.
I suggest you rerun your defaults command and set the history to at least 100. I have mine set to 500.
If you haven't used a clipboard-history utility on the Mac before, you've missed out on very useful functionality.
I use LaunchBar as my daily driver, Keyboard Maestro as backup and for more literal searching, and Paste (at need) for syncing between my devices.
-Chris
Thank you @ccstone
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.
Thank you!
I haven't. It won't run on my Sierra system, but I'll probably install it on my MacBook Air (Mojave) box and give it a look.
-Chris
@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.
Wow! this is huge!
So, then the user should ==never set KM Clipboard History to zero==.
And, IMO, KM should prevent this from happening.
So if a user wants to minimize the storage used by the KM Clipboard History, then he/she should set to ==no lower than 1.==
I will update the KM Wiki to add this notice/alert.
To all KM Users, here is my suggestion:
If you find that either the KM Editor app and/or KM Engine is running much slower than previously, then double-check both the KM Clipboard History, and the KM Global Variables for large entries, and delete them if at all possible.
Hey Peter,
I have two specific comments.
A user should not have to troubleshoot this problem – there should be no problem. We've had this come up 3 times or so on the forum in the last year, and it's been a pain to diagnose.
⠀⠀a. The curious thing is that one or two of the users had NO
⠀⠀idea this setting had been changed on their system. (One did know.)
In my opinion this is one place you need to overcome your reluctance to add new preferences. All good clipboard managers I've ever used have had such a setting. It's a disservice to the user to not let them adjust the setting without having to jump through hoops – most will NEVER even know there IS such a setting.
-Chris
No, this is specifically the point, to disable Keyboard Maestro from reading the clipboard in general.
Setting it to 1 does not accomplish that, since Keyboard Maestro will still read the clipboard every time it changes, which for some badly behaved applications causes undesirably consequences. Generally it would be better to exclude them than set the history to 0, but the results would be the same either way.
This is exactly why I do not have a preference for this setting, and if I did it would only be within a range, and not down to 1 or 0.
Once people configure private settings they are off in the wilderness on their own, with consequences that cannot be predicted.
I think a range would be fine as long as it was flexible enough.
I despise the way Objective Development does LaunchBar's Clipboard History:
I want to be able to enter a specific number of items or days and not be limited to what they think is relevant. Unfortunately they haven't listened to my arguments over the years.
I have my Keyboard Maestro Clipboard History set to 500, and it's saved me from myself more than a few times.
-Chris
Peter, this is very confusing, and somewhat contradictory.
I sincerely doubt that the large majority of KM users would want to cause the KM "Copy" Action, or the "Type a Keystroke of ⌘C" to ALWAYS fail.
I'm going to guess that the "Copy" Action, or some type of Clipboard processing is one of the most used functions of KM.
What does this mean? Are you referring to setting of KM Preferences by command line?
If that be the case, then you should provide a BIG WARNING at the top of that section of the KM Wiki that clearly states the danger of setting these preferences.
All of this points to the need to provide for setting of ALL KM Preferences via UI in the KM Preferences Window. There you could control and ensure valid settings, as well as provide a popup warning if the user is making a change that can have a major impact.
Why not put all of the preferences you currently provide via command line in the Preferences UI, in an "Advanced" tab that hides it from the user unless the user specifically clicks on that tab.
I never said that fails.
The Copy action times out because as far as Keyboard Maestro is concerned, the clipboard never changes.
The Command-C works in both cases, the clipboard is copied, Keyboard Maestro has just been instructed not to read it and so it does not change.
Yes. Any of those preferences can change at any time, or can have unexpected consequences. That is why they are not in the application.
And I have no desire to do that because that locks me in to what I can change in the future, which again, is why these preferences are not part of Keyboard Maestro proper.
Preferences and ancillary features have long term costs that have to be managed to ensure Keyboard Maestro can grow and change with minimal restrictions, and the hidden preferences are part of this, providing things that people want to do now, but without guaranteeing their support in the future.
Peter, I don't understand.
How does providing the preference in the Preferences Window lock you in any more than providing it in via command line?
Obviously you can change the preferences exposed in the UI any time you want to.
If you need to make a KM update that requires that the preference be changed or eliminated, then you can obviously also do that as part of the update.
By providing the preferences as part of the UI, you do this:
By providing the "hidden" command line preferences in the Wiki, you make it much harder, and much more dangerous for the user to change preferences.
What happens if the user has made a change to the "unofficial" command line preferences, and you make an update to KM that requires that preference to be eliminated or changed?
I have adjusted the behaviour of the Copy action so that it does not timeout when the clipboard is not read (either because the application is excluded from the clipboard history or the clipboard history is limited to 0 entries). The clipboard is still not read by Keyboard Maestro in this case, not until it is actively used by an action.
So, after a Copy Action, if we have a Set Variable to Clipboard, will that work as expected?
Yes. It already does except that the Copy action will timeout, if you disable the timeout or use Command-C instead it would work fine now.