I have a real outlier situation that I think broke, or else I was using it wrong.
For a long time GIMP has had a problem with KM's clipboard manager. (It's a GIMP bug, not KM's fault.) So I have a macro that turns off the clipboard manager when GIMP starts, and turns it back on when GIMP quits.
Here's how I turned it off:
I'm sure I got this from Peter at some point in time, because, I mean, how else would I know it?
Anyway, with version 9, this actually caused KM to never see anything copied to the clipboard. The clipboard worked for everything else, just not within a KM macro. And fortunately I realized this only happened when GIMP was running.
So I did what I think is the obvious thing, and changed the 0 to 1:
This solved the problem. So I don't know if I was using it wrong before, or what, but, well, there it is.
I can't imagine anyone else encountering this problem, but if they do, then at least it's documented somewhere.
Dan, I don't know the nature of the issue with GIMP, but have you tried just adding it to the Clipboard History Ignored App list in KM Editor > Preferences > Excluded
Nope, I never saw that! I'll give it a try and see if it works. The issue has gotten less frequent with the latest version of GIMP, so I don't know how long it'll take to see if it works. But I'll set it up right now.
The macros to log in into Apps using data from 1Password fail.
They worked on 9.0 with several 0.2s pauses, but that no longer seems to work properly on 9.0.1. Sometimes the copy action is done too early (as a result copying the credentials from the first item in 1Password instead of the first search result) and sometimes too late (as a result a wrong value in a variable).
I'm experimenting with the clipboard change detection and image detection to make it more robust.
EDIT: Also the engine is using 100% of the CPU a lot of the time...
EDIT2: Image detection and/or clipboard detection is even more unstable than the 0.2s delay I used previously. Using a 0.5s delay instead seems to work fine so far... Rather disappointing, since I would prefer checking for a desired outcome above using a random delay
Can you post one of your 1PW macros, changing any sensitive information.
In order to debug and fix, we need to be able to reproduce the behavior you are seeing.
Hi @rob, the problem should be the URL
The support at Agilebites know about the problem and some of them have already commented on it in the 1P forum.
Unfortunately they haven't got it fixed for months.
I had the problem that the locked 1Password Mini hangs when using the URL.
If it was unlocked, it worked fine with the URL, too.
In this article I will show you my changes:
In my macro (video) I set the pauses to 0.8, but meanwhile I replaced them with pauses of 0.2 and it also works smoothly.
Sure. The Open URL will ask 1Password to do something, and it will do it in its own time, so a pause may be needed after that.
And after simulating the ⌃⌘C, then you need to pause until the clipboard changes (as described elsewhere, as done by the Copy action, but that only works with ⌘C).
So those delays would be expected to be necessary.
I understand that pauses -or something better- are needed.
I thought detecting an image/text in 1Password and a password change would be more robust, but I can't get those to work properly, while the pauses seem to work.