I'm not saying you do, just saying what S+ is seeing.
So imagine you have your foreground window script turned on. Every single time a window gains focus, which happens a LOT, the foreground window script is executed.
Let's say you have Notepad open and focused, so X1 would not have clicks consumed by S+ (because of the foreground window script).
You have Opera visible, next to Notepad.
While Notepad is still the active window, you move the mouse over Opera and click the X1 button.
The X1 button down event is NOT absorbed by S+, because the setting still says to not consume the X1 button.
However, once the foreground window changes to Opera (well before you've released the X1 button), the foreground window script executes and since Opera is now the foreground window, it changes the setting to consume X1 click events.
Note that this all happens very quickly.
Between the time you pressed the X1 button down and released the X1 button at least 100 milliseconds have probably passed.
Now that S+ is consuming X1 click events, it absorbs the release (up) of the X1 button. So now Windows still believes, and treats, the X1 button as being held down even if it is no longer physically being pressed down. That's the way low level hooks, like S+ uses, work.
Now usually, if you just press the X1 down and release it, this would reset the state of the button within Windows.
But if S+ is still consuming X1 click events, it will not.
Hopefully this makes sense.
I'm not saying this is definitively what happened, just one possibility.
It's also possible that that the mouse has a hardware problem with the actual X1 switch where it gets stuck in the engaged position.
Edited by user Sunday, August 25, 2019 6:21:50 PM(UTC)
| Reason: Not specified