I have setup macros for renaming files In CaptureOne. Depending on the letter needed, the first Macro sets that Letter as a variable like this Var Rename - A [clipboard].kmmacros (2.1 KB)
and Var Rename - B [clipboard].kmmacros (2.1 KB)
Which is exactly the same except for setting variable to "B"
Then each of those macros execute this macro [VAR] Rename with Clipboard.kmmacros (3.0 KB)
which looks like this:
To explain further, we use the clipboard to re-name images with CaptureOne. CaptureOne is setup to include the clipboard contents in the image name initially. These macros are designed to quickly re-name to the correct SKU if it wasn't set to clipboard when the image was taken. Hence File/Rename Image, then ⌘V to paste the correctly copied SKU followed by "_" and the Correct letter "A" or "B" Then ⇧= simply sets the color tag and ⌘D processes the image.
These work fine on 15 or so Macs, but we have 1 Mac that is going screwy when hitting ⌥+F1 to execute the first macro above. ⌥+F2 works as expected on the trouble Mac. The only difference between these is that the first sets the variable as "A" and the second sets it as "B" then both macros execute the same follow up macro.
I tried running the debugger on the trouble Mac, but it's not catching the problem. Basically when hitting ⌥+F1 to execute the first macro, CaptureOne fires the camera, zooms in on the image and then the Mac goes into screen saver. Any thoughts what may be causing this, or how I can trouble shoot?
Would have been nice to have the question at the top instead of at the bottom of the post 
Some of us (me) have sort attention spans ("Oh look! Something shiny over there!")
My first thought is that there's a shortcut to the screen saver, and it's interfering with one of your macros. So check to see what the shortcuts are set to, whether the mouse ends up in a corner that turns it on, whatever.
As for debugging, and I don't no how feasible this is with multiple computers, but the simplest way is to put a Prompt statement somewhere in the macro chain, to narrow down where it happens.
If it happens before your Prompt, then move the prompt earlier on the macro chain, otherwise later, until you find it.
I usually just stick a plain old Prompt statement with nothing added to it, to save time.
Now, if this is going to affect the other computers at the same time because of macro syncing or something, and bear in mind I've never used macro syncing so I'm talking out of my butt here, either turn it off temporarily (assuming that's even a thing you can do) or make a duplicate set of the macros for testing. But be careful with this option, because you'll need to change any embedded "Execute Macro" statements to use the testing version of the macro.
Well it would have been great to have your solution before that little
rant! TOTALLY JOKING! Sorry about that I knew my post was getting wordy,
but I will keep in mind for future posts what you suggested and get the
point out there quicker.
Good call on the prompt thing. Someone’s actually on that computer today,
but I’m writing test macros with prompts in between each step. I’ll get to
the bottom of this. I checked the Mac shortcuts in system prefs, and
didn’t see anything that would be causing trouble.
Thanks for the tip!
Don't worry about it. It's actually me, not you.
You don't really need that, unless you can't run the KM editor on the workstation in question. The problem with putting prompts in everywhere is that your problem might be a timing issue, and the prompts could interfere with the timing.
If you can't run the KM Editor on the workstation, let me know, and maybe we can brainstorm.
If you CAN run it there, the workflow is much easier. It goes like this:
-
Put a prompt after where you think the problem might be.
-
Run the macro and see if you get the prompt after the problem or before.
-
Then start narrowing down by finding an actual "before the problem" location, and an "after the problem" location.
-
Once you have that, it's either a matter of eyeballing the source, or more common, put a new prompt somewhere in between the "before" and "after", and repeat the process until you catch the bugger!
*AKA Binary Search
Like I said, if you can help it, don't change the timing. The Heisenberg is certainly in action here, when you're debugging!
Ok, that makes sense. Thanks again. I’ll reply again after trying that.