I use the Clipboard Change trigger a lot. I've encountered one problem with it that I can't resolve. The problem is if I use the "Insert text by pasting" action in my macro that is triggered by a clipboard change, it causes the trigger to trigger again. Essentially I get an infinite loop. I can see that the "Insert text by pasting" needs to change the clipboard, but surely there's some way to make this work.
I've tried a couple of things:
Disable the macro group before I call the "Insert text by pasting" action (I can't get that to work, but I don't have much knowledge about disabling macro groups from inside a macro. Is there some way to disable a macro programatically instead of a macro group?)
Add code to the top of my macro which determines the source of the clipboard change (but there doesn't seem to be any code that I can use to determine if the change is caused by a macro or by the user, even the TriggerBase token doesn't help)
For now I've stopped using "Insert text by pasting" and replaced it with "insert text by typing" but in my circumstance that's about 100 times slower.
You were on track with your first idea. The way to disable a macro (or macro group) programatically is to include the Set Macro or Group Enable action in your macro so that it disables the macro when it starts and enables it again when it ends. As an example, this test macro worked for me without infinite looping:
My macro accepts text from a separate process that it has no control over. For the most part that process just creates alphanumeric text. Then it processes that text and used the Insert Text by Pasting to paste the text into a Keynote presentation. You can think of it as a cleanup of the text.
Both the incoming text and outgoing text are primarily alphanumeric. At the moment I can't see how to make a decision based on the content, as the incoming and outgoing context are very similar.
Thanks for helping, though.
However there seems to be a problem with GG's macro. I've had to put a pause statement after the Disable and Enable macros. My theory is that the Disable/enable macro isn't instantaneous. Is that correct? I haven't had a problem since I inserted a little pause there. Could I be right about the delay?
Do you get duplicates? Because if not, you could just detect it was the same clipboard you just pasted and ignore it.
Alternatively, you could remember the last time and ignore the change. And if the period between clipboards is acceptable (which it should be or you could get in to trouble with the clipboard changing before the target application processes the ⌘V you could simply add a Semaphore Lock action at the front of the macro, and have it time out quickly, abort the macro without notification, and include a small pause at the end of the macro to wait for the application to process the clipboard.
The chance of duplicates is negligible. So that may work. This proves I am worthy of my nickname, and you are worthy of being called a Maestro.
I think your alternative is about checking the timing. That not quite as likely to work (because the process generating new clipboards is asynchronous) but it's still a great idea that I didn't think of. Thanks. It probably could work too, most of the time.
But on the other hand GG's solution seems to work perfectly for me, as long as I placed a brief Pause action after the macro enable/disable action. Is it true that the enable/disable action may not be enforced instantly resulting in some clipboard changes to be missed? I seemed to be experiencing that so I inserted a little pause and didn't have any more problems.
The Semaphore Lock method is probably better than Disable/Enable for this case. They should be more or less the same behaviour in theory.
Disabling should happen instantly.
However the processing of the ⌘V is also asynchronously handled by the target application.
But regardless of all this, if the clipboard change is asynchronous, then you can get the case of:
You set the clipboard in the macro (including with Insert Text by Pasting
You simulate the ⌘V
The async clipboard change happens
The application processes the ⌘V and reads the wrong clipboard.
Step 2 and 3 could be in either order.
So unless there is a minimum time between clipboard changes from your async process, there is no way to guarantee reliability. And if there is, the semaphore lock (or disable/enable) should work.
I never thought of the semaphore lock to resolve this. I think I see how it could work here. Thanks, Maestro.
I can't see the asnych process taking less than one second before setting the clipboard.
Reliability here isn't crucial. I've built a prototype product using KM, which impresses and entertains me to no end, and now I think I should start making use of that Apple Developer license I bought last fall and start trying to port this baby to iOS. I'll use my prototype to show potential users of this product to get feedback. I may have to buy a laptop to demo it with as I don't want to haul around my iMac.
I'll probably succeed with the port but I have a steep learning curve, as I have to figure it out on my own with nobody to help me. It's always the beginning of a new language that's the toughest. Should I look into maybe those Apple Swift playgrounds first? Or just watch some xCode tutorials on YouTube?
My program on iOS won't be that complicated. Mostly just processing text files given some audio input with SiriKit. My text processing skills are good enough. It's SiriKit that worries me a bit (not to mention xCode.) Here on macOS I was able to use the Accessibility Dictation mode as an entry form of SiriKit. It works pretty nicely, at least for a prototype.
For the record, I tried the Semaphore Lock action first when making my example macro, and for whatever reason it didn't work for me, whereas the disable/enable actions did.
Basically, it should just be a Semaphore Lock, with any (probably unique) name, and a timeout of perhaps half a second, with no notification, and aborting the macro. But you also need a pause at the end of the macro, after the Insert Text by Pasting, to keep the macro running long enough for the application to process the ⌘V (Keyboard Maestro does wait a short time, but it's deliberately fairly short, generally enough).
