I've had this problem for a while. It might correlate to the KM9 upgrade.
Some macros fire outside their application availability. IOW, a macro in a group whose availability is limited to the application TeachText will trigger in another application.
Needless to say, this causes some real havoc and has the potential to destroy work, depending on the misfiring macro. When I figure out which macro is firing, I can go to the parent group, delete the restriction and then add it again, and that will fix it.
Is this pilot error, or some kind of a bug? Are there best practices to avoid this?
I have not observed this behavior, which is indeed very strange and potentially unsafe.
But to debug/fix, we must be able to reproduce the issue.
So could you please upload your macro that exhibits this behavior?
Unfortunately, I've fixed all the macros by refreshing the application availability of their parent group. I don't think the problem is local to the macro, it seems to be in the parent group's availability setting.
This may be a one-off glitch from updating to KM9. I think I'll prophylactically reset all the group availability settings.
I'm open to any other insight, of course.
When you export a macro, it also includes the definition of its Macro Group, so that when someone else imports it, KM creates the Macro Group as well.
OK, we'll consider the issue closed until/IF it occurs again and you can provide us with the macro.
Okay, it happened again, and with a macro that has misbehaved in this way before.
The macro's availability is limited to the app OmniOutliner.
It shows up in the conflict palette when I hit the Return key in Dynalist, which should trigger another macro that is only available in that app.
Here is the macro:
New Line and clear variable.kmmacros (2.1 KB)
OK, I think I see the issue:
@peternlewis has noted many times that using a Type a Keystroke that is the same as the trigger for a macro can cause unpredictable results.
While I agree that when OmniOutliner is NOT frontmost, this macro should never be triggered, I have to admit that it does fall in the category of "unpredictable results".
So, I'd suggest that you change all of your triggers that are "Return" to be "Opt-Return" (or some other modifier key).
@peternlewis, can you explain how it is possible to trigger this macro when OmniOutliner is NOT front most?
Thanks for pointing that out.
Would it be equally unstable if I used a Device Key as a trigger instead of a hot key?
That issue would not cause the macro to be active when it should not be - but it could cause the macro to sit there looping indefinitely while the macro re-triggers itself repeatedly, and that could result in the appearance of the macro being active when it isn't.
1 Like
FWIW, I had it happen again with another macro that has the return key as both the trigger and part of the macro action:
This macro is for Dynalist, an outliner. It takes a Return and makes sure the current outline item is not split by the Return.
As with the previous macro, this one began firing outside of its availability restrictions.
Would it be possible to have KM caution/reject this kind of setup?
