BTT fails to recognize when an application is running which triggers a configuration set.

=Version and Timing=
This issue began earlier today (2023-08-27) after I updated to the latest regular release of BTT. I then installed the latest Alpha and the issue was not resolved. I then rolled back to the version I was running before this morning, 4.184 (2403), and the problem has not recurred since the rollback.

=Bug Description=
I run some Windows applications using WINE, specifically the commercial version of WINE called Crossover. Because these Windows applications require somewhat different mouse and keyboard input than do my Mac applications, I use a different configuration of BTT for all of my WINE applications. I have added each of the specific application names to the trigger for my second BTT set as well as WINE's generic "wine-preloader" and its variations.

Until earlier today, this always worked perfectly. BTT always picked up when one of my WINE applications was the focus and used the configuration set for those applications.

Today, I updated to whatever was the current regular release of BTT (sorry, I failed to note the version number at the time). Almost immediately, I noted that BTT was intermittently failing to apply my second configuration when one of my WINE applications was the focus. Switching to the Finder and back usually "fixed" the problem temporarily but at some point – a few or many minutes later – BTT would engage my first configuration even though the WINE application had remained the focus for that entire time. When that happened, it didn't return to the second, intended configuration by itself but required a focus change to the Finder and back and in several cases required me to restart BTT.

In addition, when this happened the "w" key on my keyboard became completely unresponsive until BTT returned to automatically switching to my second configuration – either by focusing the Finder then focusing back to the WINE application or by restarting BTT. That is extremely weird, I don't have the "w" key on my keyboard configured through BTT in any way.

I then updated to the latest Alpha (sorry again, I did not note the version number) and the problem continued.

I then rolled back to the version I was using yesterday, 4.184 (2403), and the problem did not recur after doing so.

=Affected Input Device=
Keyboard, possibly mouse. Both are Logitech:
Logitech MX Keys for Mac
Logitech G604 Lightspeed Mouse

=Device information=

  • Type of Mac: 2019 21.5" iMac (3.6GHz i3)
  • macOS version: Ventura 13.5.1
  • BetterTouchTool version: Currently running 4.184 (2403) WITH NO PROBLEMS, but whatever version was released today (2023-08-27) both regular and Alpha versions cause the problem. (Sorry, I do not wish to update again just to get the version numbers because then I'll have to roll back a second time.)

What exactly do you mean by "different configuration"? How is it set up?

Sorry, that must be the wrong nomenclature. Perhaps a pair of screenshots will explain what I meant.

Ah, these are called "Conditional Activation Groups", I'll have a look!

1 Like

I can't seem to find a specific issue with the new versions, all my tests seem to pass fine.
However I found a general issue which could make the CAG's stop randomly, this would be fixed in 4.198 alpha now.

I installed 4.198 and within about a minute the problem recurred. I lost the ability to use the "w" key on my keyboard and I could not disable caps lock. Switching focus to Finder and then back to the WINE application had no effect. I had to quit out of BTT in order to begin writing this feedback.

I then restarted BTT 4.198. A little experimentation demonstrated that using the mouse button which I have configured in my WINE "Conditional Activation Group" as the SHIFT key (shift-down and shift-up as two different actions) is triggering the problem. I again had to quit out of BTT in order to continue writing this feedback because apparently the problem is that the shift-down action is being performed but then the shift-up action is not being performed.

Reverting again to 4.184 and I can use that mouse button as intended: As a replacement for the SHIFT key. Both shift-down and shift-up are working properly as that mouse button is depressed and then released.

So my initial impression, that the problem is related to the triggering of "Conditional Activation Groups" was incorrect. At this time, I believe the problem is that the shift-up action which I have configured in my WINE group for that mouse button is not working in 4.198, although the shift-down action is working. I can consistently trigger the problem using that mouse button in 4.198 and the problem never occurs with 4.184.

Ah that makes more sense, I think it's not related to CAGs but to the mouse button setup. There was a change in the recent versions. I'll check that :slight_smile:

1 Like

Can you tell which mouse button you are using? Is it left / right mouse or some other mouse button?

The mouse button by default registers in BTT as Button 3. In my default "All Apps" Conditional Activation Group, it is set to behave as the COMMAND key. In my "WINE Apps" Conditional Activation Group, it is set to behave as the SHIFT key. To emulate the behavior of a modifier key, as you know, it is necessary to set two actions, one for button-up and one for button-down.

I hope it's fixed in the 4.199 alpha, but I'll only be able to verify tomorrow (currently don't have a mouse with me)

1 Like

Just tested for couple of minutes so far, but Alpha 4.199 (2419) seems to have resolved the issue. Great!

Your quick response to this report has been really amazing. I appreciate not only the quick turnaround and resolution to this issue but the pleasant way you interacted with me here. Thank you!