Conditional Activation Group not working

Describe the bug
Conditional activation group is not properly restricting the scope of keyboard shortcut.

I am trying to prevent command-W from closing certain windows in Microsoft Outlook. Despite the restriction specified in the conditional activation group, this suppression is affecting all windows in all applications.

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
Keyboard

Screenshots


Device information:

  • Type of Mac: MacBook Pro
  • macOS version: 10.12.6
  • BetterTouchTool version: 2.660 (968)
    Additional information (e.g. StackTraces, related issues, screenshots, workarounds, etc.):

Note: Before bug reporting, please make sure you have the latest version of BetterTouchTool and that you have already tried to restart your system :-). If you encounter a crash, please attach a crash log from the macOS Console.app from the "User Diagnostic Reports" section.

Thanks for reporting!
Would be great if you could try v2.669 alpha.

Sorry for the delayed reply. I installed 2.674 alpha and tested. Now, the action is confined to the desired application but the second part of the conjunction (All) is not discriminating between conditions that meet the specification and those that do not. To be specific, if neither of the two conditions under the disjunction (Any) are true, the overall expression still seems to evaluate to true.

I have a similar problem where conditional grouping is not working. In my case I'm limiting the conditions into a specific app using the "appName" and to a scroll area using "focusedElementRole" set to "AXScrollArea". The second condition does not seem to take effect whatsoever, because any shortcut I made also gets triggered inside "AXTextField" too. I have tried anything I could possibly imagine but no success. Also sometimes another global conditional group for only "AXTextField" works randomly, so it's not completely reliable. For example, try swapping "^h" to "backspace" and see how it goes in different places.

This depends very much on the specific app's support for accessibility.
Some apps only send notifications about the changed focused element sporadically or not at all.

Also AXScrollArea is usually not the focused element. In which app are you testing?

I'm testing it inside RoboFont. I want to change WASD keys to arrows inside the app when I'm designing inside the glyph window so I don't have to move my right hand when I want to use arrows. But this also takes effect in the text fields and messes with the text I'm typing. I made another shortcut to disable BTT, but that specific shortcut doesn't work. So my only solution was to use focusedElementRole condition. I'm not sure if the source of the problem is Robofont, because in the BTT when the focus changes it shows that the role also has changed on the bottom. Also for a test, I made only one condition and that's for when the role of the element is "AXScrollArea" and still it gets triggered inside "AXWindow" anywhere. I checked it inside the BTT and it shows how the focus is changing but it doesn't take effect.

Could you maybe post a screenshot of your setup? Which version of macOS are you on? (I have only tested this on Mojave so far)
I just tried with Finder to make sure everything is still working like I intended

The first triggers when the search field in Finder is active, the second when the file list is active. It is important that ALL is selected on the top left when matching app + role.


As you can see in the screenshot the focus is on the AXScrollArea and "All" the conditions apply. If I change the focus on a TextField in RoboFont, BTT also shows the focus has changed. The crazy thing is that when I'm typing this comment in a browser window, I had to disable this specific conditional activation group to stop it from interrupting my typing. My OS X version is 10.13.6. I'm starting to think I should abandon this feature since it's not reliable.

I am the original poster, and despite several subsequent BTT updates (with release notes indicating maybe the problem has been worked on), I continue to be unable to get this to work. My objective is to prevent command-W from closing certain Outlook windows. When I enable this rule, it prevents command-W from working in any application.

Which version are you on currently?

Version 2.697 (1002)

I think I may have found an issue that could lead to such problems in certain situations. Would be great if you'd test v2.699 alpha

Thank you for your work on this. Now the rule obeys the appName clause. It is only active when Microsoft Outlook is active.

Unfortunately, the second half of the conjunction (All) is not having any effect. Command-W is suppressed for all Microsoft Outlook windows, regardless of focusedElementRole or windowName. As one example, this screen shot shows that focusedElementRole was AXGrid and the windowName did not begin with "Searching". Nonetheless, the rule was active and command-W was suppressed.

As a general suggestion, it would be useful if that stats information at the bottom would also show the full evaluation of the rule, either "active or "inactive".

Best,
John

Very weird, I tried to reproduce this with various apps but it seems to work fine on my machine now.
I don't have Microsoft Outlook though.

It's a good idea to show the evaluation state of the condition. I'll add this. I'll also add a way to trigger a action when a conditional activation group becomes active (e.g. "Show HUD" to see what's going on exactly)

I have just added this in v2.700 alpha. The text will now become green if it evaluates to true.

I have also added two new triggers to the "Other" tab: "Conditional Activation Group Activated" and "Conditional Activation Group Deactivated". This allows you to trigger stuff when one of your activation groups becomes active / inactive.

Also I found a bug that caused the "Sub Role" condition to not, this could potentially also be useful for you.

Just tried to Check for Alpha Version Updates but it tells me 2.699 is the newest version available.

I found it by manually downloading from the releases folder. Will test.

The test is green or black at the appropriate times, but the Command-W is disabled regardless, when Outlook is the foreground application.

Oops, the Command-W is suppressed in other apps again. The text is black for those.

Very weird.

You you have the default keyboard mode activated or did you check "Always use old keyboard shortcut implementation"?

//edit: made some more changes in 2.701 to hopefully also support conditional activation groups with the old keyboard implementation