[v1.5.10.8] {STATE_KEYSTATE:} does not work with passthrough disabled

[Pfeil]

When a command is triggered using "When I press keys" and the "Do not allow key to be passed through" is checked, the "{STATE_KEYSTATE:}" token will return 0 even though the key is held down.

E.G.

Code: [Select]

Start Dictation Mode (Clearing Dictation Buffer)
Start Loop While : [{STATE_KEYSTATE:INS}] Equals '1'
End Loop
Stop Dictation Mode
Write '[Purple] {DICTATION}' to log
Will not run the loop.

Additionally

Code: [Select]

Write '[Purple] {STATE_KEYSTATE:HOME}' to log
Pause 1 second
Write '[Purple] {STATE_KEYSTATE:HOME}' to log
Pause 1 second
Write '[Purple] {STATE_KEYSTATE:HOME}' to log
Will always return "0". Releasing and pressing the key will not work either, and merely re-triggers the command.


While on the subject, perhaps a "{STATE_SHORTCUTKEY}" token could be useful. It would save looking up certain keys in the help file, and if the "When I say" key changes, the check is always done on the proper key.
I'll put in a "formal" feature request if you prefer things more organized.

[Gary]

I'll look into it!

[Gary]

I see what was going on.  When the state is checked, VA is using an api call to get the state of the key.  When the key is not passed through, the key press is, 'handled' and the key no longer appears to be down outside of VA.  I think this is fixed now... I put a build out in, 'unofficial' if you would like to get it.

Thanks for catching that one.

When you are referring to, '{STATE_SHORTCUTKEY}' are you just talking about the keys that were pressed to invoke the command?  There would have to be multiple tokens for that... {STATE_SHORTCUTKEY}, {STATE_SHORTCUTKEY_WIN}, {STATE_SHORTCUTKEY_CTRL}, etc.  The modifiers would be '0' or '1'.  Am I on base here?

[Pfeil]

I think this is fixed now...

It is, as far as I can tell

When you are referring to, '{STATE_SHORTCUTKEY}' are you just talking about the keys that were pressed to invoke the command?  There would have to be multiple tokens for that... {STATE_SHORTCUTKEY}, {STATE_SHORTCUTKEY_WIN}, {STATE_SHORTCUTKEY_CTRL}, etc.  The modifiers would be '0' or '1'.  Am I on base here?

Hmm...I haven't yet had a need for a trigger using modifiers; I tend to use a single key.

Modifiers also make the use of "Shortcut is invoked only when all keys are released" more likely, which is mutually exclusive with holding down keys.

I don't see what tokens like "{STATE_SHORTCUTKEY_WIN}" would add; You can't infer whether the shortcut has a certain modifier from it, so they're essentially the same as "{STATE_KEYSTATE:WIN}".

Either way, I feel having the token return true while all shortcut keys are held down would work well enough for most scenarios, as you can still check the individual keys using the normal "{STATE_KEYSTATE:}" token if you need to go more in depth.

Additionally, should multiple shortcuts for a single command become a feature in the future(say in case you want LWIN + X and RWIN + X to do the same), the token in that form could work for all of them.