This action will trigger whenever the clipboard changes, and then:
(1) for text clipboards, give you the word/line/character count (if >1)
(2) for image clipboards, give you the pixel count, point count, and DPI count
(3) ALSO for image clipboards, determine the language of the text in the image (amazing!!)
(4) place these statistics in the Menu Bar at the top of your screen.
If your text doesn't contain any of the words in the LocalLangaugeData, then the result will be UNKNOWN, otherwise the langauge selected will be the one with the most words in it.
If there are any other statistics you want, I'd be happy to add them.
Hi Airy, thanks for your macro, I was just about to get started on something similar!
I might be missing something obvious, but your macro doesn't seem to actually display anything?
Sure!. I should have included screenshots. Here's an image of what it looks like on my screen. I've included two screen shots, one when there is text in my clipboard, and one when there is an image in my clipboard.
As you can see, when there is text it the clipboard, an icon says "TXT", followed by the word count and line count, plus the first/last three characters of the clipboard, plus the word "Unknown" which means it couldn't detect any language in this clipboard.
The second image shows a tiny copy of the entire clipboard, followed by the X/Y pixel count, point count, DPI values, and "Unknown" which in this case means it couldn't find very much of any language in the image.
If you don't want the output to go into the System Menu, I can probably modify the macro to place the output into some other location - perhaps a global variable?
I thought that was what you meant, and I wonder why it doesn't display anything for me. I was running Ice and thought that was the reason, but your macro also doesn't display anything if I quit Ice.
I checked the KM log and this is what I get when I your macro runs:
Execute macro “Clipboard Analyzer v2” from trigger System Clipboard Changed
Action 16002068 failed: Task failed with status 1
You diagnosed the problem to some degree. Your copy of my macro is failing before it reaches the first statement in the macro.
A similar problem occurred in this thread. You may want to read it.
However if you want to run my macro with a hotkey trigger, or a periodic trigger, or just pressing the Run button in the KM Editor, you should at least see my macro running then. You can still run my macro using some other means.
Did the Clipboard Analyzer macro work for you, @_jims or for you, @Nige_S ? Knowing this will help diagnose if the problem is with his environment, or with the macro.
I haven't tried it. But going solely by the image and error posted...
egrep returns a 1 result code when there is no match found, even while the -c option is returning the value 0. KM treats a shell script action's final result code of anything but 0 as an error.
My guess is that you need to turn off "Failure Aborts Action" and "Notify on Failure" in the action's options if setting LocalTally to 0 is a valid outcome.
The egrep command is in a Try/Fail action, and if it fails, it goes to the Fail clause and returns a value of 0. That's how I fully account for that situation. And it works fine for me.
Well, if nothing else comes of this you've now a way of handling similar cases without the "Try/Catch" action
I'm stumped, then. If the action is erroring inside a "Try/Catch", there can't be a report in the log. If there's a report in the log the action can't be in a "Try/Catch".
After reading and studying your comments, I may possibly have found the problem. The error message in the log file that he sees is not a message that reflects the stoppage of the macro. In a TRY block, errors go into the log file even though the macro continues to work. Technically, you were wrong when you said "If the action is erroring inside a "Try/Catch", there can't be a report in the log." Indeed, errors will show up in the log file when inside a TRY block and the macro still continues normally.
So I'm staring at this macro, wondering why it works for me and not for him. I have a theory. You see, the group that the macro is in contains critical attributes that are required for this macro to work. My theory is that he moved my macro out of the group it was in and placed it in another macro group without telling us. If he did that, then he would get precisely the results that he is now getting. It's just a theory, but it would explain perfectly his results. Let's see what he says about this theory. The group must contain these attributes. Even if he didn't move the macro, he should validate that his group contains the following:
Not just technically wrong -- totally wrong! I must have set up something weirdly in the quick test I did. But it did let me crowbar in a "Catch 22" reference, so I hope that makes up for it
Ah -- so the macro is running, the error reported is an artefact of expected behaviour, it's just that the "display settings" aren't right at the Group level? Sounds promising.
Which does make me wonder if this is the right way to handle single grep (and variants) commands. grep is unusual in its use of result codes -- perhaps we need to handle it differently so that KM doesn't see an error when there was none. Something as simple as
