I use Pastebot, and I've noticed that sometimes after I access Pastebot to paste an older clipping, KM doesn't seem to know that the clipboard has changed?
If I got in to other apps and just paste (cmd-v), it pastes what I expect. But when I invoke a macro that uses %SystemClipboard%, it will use what had been in the clipboard previously. I end up having to cut/copy something else, then cut/copy the text I need in the clipboard again in order for KM to get the correct value.
Keyboard Maestro tracks the system clipboard changes by tracking the system clipboard seed and re-reads the clipboard when that changes. It could be that the clipboard is being changed by Pastebot, but then the clipboard is unreadable, or that Pastebot is doing something weird which is allowing the clipboard to change without the seed changing.
I'm afraid I don't really know where to start in suggesting how to resolve this.
I figured I'd share a quick video too, incase that helps at all.
The strange thing is that in the KM Editor, below the "Set variable" action, it shows the correct value when pasting from Pastebot, but it doesn't use that value when the macro runs.
In the gif below I did the following:
Paste - this sets up the "previous clipping", and also shows that the clipboard and KM editor agree on the value.
Open Pastebot, select an older clipping which pastes it. This is also reflected in the KM editor.
Invoke the macro. When I do this, it uses neither of the two clippings shown previously.
Out of interest -- what happens if you change the typed text trigger to, say, ;track?
Just wondering if the leading ? is, somehow, querying the Pastebot history for the most recent item containing "track" -- which would match what's being pasted.
I think that it's a different/opposite problem though.
In the linked post, they were trying to "force feed" the Pastebot sequential paste function. So KM was trying to set the clipboard, which if Pastebot's sequential paste palette was open, should trigger it to add to Pastebot's history and therefore add to it's sequential paste queue. So here it was KM setting the clipboard, Pastebot was basically just too slow to see the changes to the clipboard.
In my case Pastebot is doing the pasting, and according to all other applications (including KM Editor) it is changing the clipboard to the newly pasted data - but the KM Engine doesn't seem to be recognizing the change when the macro runs.
My expectation, given what Peter mentioned above, was that when I pasted from the Pastebot history, that the KM Editor would also not update it's preview of the %SystemClipboard% token.
@peternlewis Just wanted to raise the note/video above before I tried roping the Pastebot dev into this. Does it make sense that the editor shows the clipboard change, but the macro/engine doesn't?
The editor does not have access to the clipboard history. For example:
So when it reads the SystemClipboard token, it reads the system clipboard directly (as would Keyboard Maestro Engine if you had disabled Keyboard Maestro’s clipboard history system).
The Keyboard Maestro Engine reads the clipboard from its own clipboard history which has not seen the change made by Pastebot for reasons unknown.
Got it. Right now, I don't use the KM clipboard history, so I disabled by setting the history to 0 items as discussed here. The macro works as needed now. Thanks!
I have the same problem I described earlier (again?) - the Editor is showing the correct value, but the executing macro displays the wrong value.
At first I tested this copying from BBEdit, but realized I could show the issue entirely within the KM Editor.
I forgot to show it in this screen recording, but I had quit Pastebot before this test, and I made sure it stayed quit while conducting the test.
I have tried restarting KM and the KM Engine. When the KM Engine restarts it gets the current value of the clipboard and seems to keep using that value (in the gif below the initial value of the clipboard when I last restarted the engine was "LocalVarName").
Just wanted to note here that this recent problem persisted restarts, so I went back in and set the MaxClipboardHistory to 1, that resolved that problem.
So the original issue I mentioned still exists now. Not great, but better than the new problem caused by setting MaxClipboardHistory to 0.
