[v1.7.3] Mouse button state cannot be checked if passthrough is disabled

[Pfeil]

While the warning popup that appears when checking the "Do not allow button event to be passed through" option in the "Mouse Shortcut" dialog and clicking "OK" states "Preventing the mouse event from being passed through will keep other applications from receiving clicks from those buttons.", it appears this also applies to VoiceAttack itself.

Running the following command(attached) with the "Back" button set as the "When I press mouse" trigger:

Code: [Select]

Begin Device State Check :  Any Mouse Button Is Pressed
    Write [Blue] 'Any' to log
End Condition
Begin Device State Check :  Back Mouse Button Is Pressed
    Write [Blue] 'Button' to log
End Condition
Begin Text Compare : [{STATE_BACKMOUSEBUTTON}] Equals '1'
    Write [Blue] 'Token' to log
End Condition
Will result in only the command execution being output to the log, as none of the conditions return true.


I also tested with the middle mouse button and got the same result.


This does not occur with keyboard keys, and passthrough does not apply to joystick buttons.


EDIT: Also applies to v1.7.3.1

EDIT#2: Also applies to v1.7.5.8

EDIT#3: Also applies to v1.8.3.21

EDIT#4: Cannot be fixed because of a technical restriction; Archived.

[Gary]

Have you tried restarting VA to see if that works or not?  I'm trying to resolve a mouse hook issue that seems to get fixed if you restart VA.  Haven't dived into this one yet.

[Pfeil]

I have restarted VoiceAttack and rebooted.

I should also mention that turning the "Do not allow button event to be passed through" option off will make the state checks work again, within the same session.

[Gary]

I found (again lol) that when the mouse event is handled, VoiceAttack (or any app for that matter) does not receive the mouse up message (I guess this is a good thing).  It's impossible to retain state in that situation, since it never appears that the mouse is ever released. 

It's probably not terrible that it is the way it is, as it's probably low likelihood that you'll be testing if a the same button you've used to trigger a command is down - and probably even less likely to test on a mouse-triggered command if any/no mouse buttons are down.  I've updated the state token documentation to indicate this, but did not update the device state documentation as it's not very in-depth as it stands. 

Thanks for catching that   I was like - whoa - I missed that somehow.  Then I started digging into it and found that it's like that for a reason (bleh lol).

[Pfeil]

Ah, that is unfortunate.

Checking the state can be very useful to distinguish between a button press and a hold, which I see the new built-in "Shortcut is invoked when long-pressed" cannot do either (as it is grayed out; This restriction is documented) while the "Do not allow button event to be passed through" option is checked; Obviously because of the same technical restriction.