Keyboard shortcut with "Prevent recursive trigger" works only once.

Bug Reports
1

Describe the bug
In Global, I use Cmd+backspace to delete previous word. (maps to Option+backspace)
In Finder, I use Del to delete file (maps to Cmd+backspace).

So I prevent recursive trigger for the Finder shortcut.

But this does not work as expected: the Finder shortcut is only recognized once by "window session", i.e. I need to move focus to another windows then back to Finder for my Del shortcut to work again. (just once).

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
Windows keyboard : Microsoft Wired Keyboard 600.

Screenshots
screen recording here: https://monosnap.com/file/V2in9XocNoyBFCNqTSBgOd7fTbQt4Z

Device information:

  • Type of Mac: Mac Mini late 2014
  • macOS version: latest Mojave
  • BetterTouchTool version: latest, v2.660 (968)

Thanks!

2

Having essentially the same issue. There's something going on with 'Prevent Recursive Triggers' messing up the shortcuts. My guess is there's a logic flaw that's blocking all future triggers, not just those that would be actually triggered recursively (i.e. before all keys are lifted, etc.). To get around this, when all physical keys are down, then use the logic to prevent further interpretation of triggers, but as soon as all keys are lifted, then you 'reset' the flag so you can interpret the next trigger.

This is purely speculation, but it makes sense from a development/logic standpoint.

3

I think this should already be fixed in the latest versions, which version are you running?

4

3.206. Is there a newer version?

5

no that should be fine. Weird, then I need to look into this again. Sorry for the issue!

7

So you have my specific use-case, I'm using the Arduino IDE, which itself doesn't respect global macOS system shortcuts set in StandardKeyBindings.dict in macOS. This is because Arduino doesn't appear to use the standard Cocoa text editing system, and instead has hard-coded logic to interpret keyboard shortcuts and it has them emulating a default macOS install.

The problem is for people such as myself who have heavily customized their StandardKeyBindings.dict file (I made mine emulate the way Windows text editing works) we need a way to correct that. That's where BTT slots in wonderfully.

So... as an example, in a default macOS install, CMD-LEFT goes to the beginning of the line. However in Windows, it's HOME. Similarly, in macOS, ALT-LEFT moves left by a word, but in windows it's CMD-LEFT.

Taking them in order, I first used BTT to map HOME to CMD-LEFT, specifically for the Arduino app. This works as expected.

I then attempted to map CMD-LEFT to ALT-LEFT, again, just for Arduino. This too worked as expected. However it also had the side effect of changing HOME to ALT-LEFT as well thanks to recursive triggers (i.e. HOME triggered CMD-LEFT which recursively triggered ALT-LEFT).

To get around that, I attempted to use the 'Prevent Recursive Triggers', but as this illustrates, then both triggers stopped working, as if they were disabled.

Side note/Tangent: I had opened another ticket with you a while ago about using BTT to modify the global key bindings in StandardKeyBindings.dict. It's macOS's built-in way to send selectors based on keyboard shortcuts.

There used to be a program called KeyBindingsEditor that was a wonderful GUI for editing them, but it seems to be abandoned lately. It used to let you type a keyboard shortcut, then pick from all the common selectors that macOS's Cocoa text system supports. I actually have no reason to think it wouldn't work for any selector, not just Cocoa text, but I could be wrong.

Either way, BTT would be a great candidate to pick up the torch left by them, especially if you added 'Send selector' as one of your trigger actions. For instance, you could make a three-finger gesture move to the beginning of the line by sending the selector for that action rather than simply re-triggering a keyboard gesture, which may be re-mapped anyway.

Here's more info on the settings in macOS:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/TextDefaultsBindings/TextDefaultsBindings.html

10

Just adding this is still an issue in version 3.346 of the app (as of 4/22/2020)

Same thing happened in a different app now... Oracle SQL Studio, although I'm pretty sure it has nothing to do with the app.

Again, as an example, I'm trying to use BTT to change inputting END on my keyboard to move to the end of the line as opposed to its default behavior of going to the end of the document. This is easy enough to achieve... set up a keyboard shortcut for END that sends CMD-RIGHT to the app instead. Simple. Works like a charm.

I also want to map CMD-END to go to the end of the document, again like windows. Since the application normally listens for END for that, I think no biggie... just map CMD-END to END.

BUT... this of course doesn't work because CMD-END maps to END which recursively triggers the one above that maps END to CMD-RIGHT so the app actually receives CMD-RIGHT, not END as I expected.

'Prevent recursive triggers' is supposed to address this, so I enable it on my CMD-END -> END trigger, and it works... for the first key-press only. If I press CMD-END a second time, the app now receives CMD-END as if the trigger didn't exist.

Worse, even the original trigger for END now stops working as well.

ALL triggers are now disabled and stay that way until I switch to a different app, then back again.

What I would expect is that the recursive triggers would only block for that specific trigger, meaning whatever output they generate gets sent to the app. Completely guessing as I don't know your inner-workings, I'm speculating you turn off all key shortcut detections, but you're not re-enabling them after you've sent out the initial key mapping. Thus, the next key press, and all future presses, are ignored until you switch away to a different app, then back again, which of course 'resets' BTT since there was an app switch, thus re-enabling the triggers.

Again, purely a guess, but it can't be that far off.

BTW, I tried a work-around which was to set the triggers to only fire if they are coming from the specific keyboard they were generated from, thinking the shortcuts BTT remaps to would becoming from BTT, not my keyboard, thus that condition would fail and it wouldn't recursively trigger, but that didn't work. Don't know if it's because the output trigger was also recorded on that keyboard so when played back it does look like it's coming from the keyboard even though it's actually coming from BTT. I didn't want to dig out an old keyboard to see if that was the case, but I will if you want me to.

Anyway, happy to hop on Skype, Zoom or anything else to show you this first-hand if it would help. May be better to see it in action if this doesn't make any sense.

I even have an app called KeyCodes that visually shows you what keys are being received by the app that can help diagnose this more.

Please address this though. This would let us fix keyboard mappings in any application to be the way we want.

11

I'm having the same issue as MarquelV, with the exact same set of keyboard shortcuts.

This seems like a common enough issue (who doesn't edit with the cursor-wise word movement and home/end?) that there probably exists a utility that does this mapping by itself, as much as I'd rather keep everything to one utility (I've already installed like 6 different things to get my Mac even close to what I expect based on my predominantly Windows experience)

12

Any update on this? Also, Andreas, is there a way to send a selector to the currently-focused app? I posted another q about this, but don't see any response. Asking here since that's a way around the issue we're dealing with here.

13

could you maybe share a BTT preset reproducing the issue described here? I think I'm not 100% sure I understand the issue because my tests for the "Prevent recursive trigger" option work fine - but I feel I'm missing something obvious. If there is an issue it should be fixable.

Sending custom selectors is not possible (AFAIK the last OSX version where that was possible was 10.5 in ~2007 when Input Managers where still a thing)