Block Specific Keyboard Keys Function (Immediate Block/Not Held Until Complete?)

[Starblue7]

I've got a loop running and there's a condition where I want to block a key right after I press it.

Code: [Select]

    Begin Device State Check :  Keyboard Key 'F1' Is Pressed
        Block specific keyboard keys  (F1)

However:

1.  It just seems that if I press the F1 key fast enough, the target game will potentially register that additional keypress in any case even before the Block Command has a chance to complete.
Is there any more proper/creative way to deal with this to lock down the key immediately once pressed?  Is it the more keys are included in the block request, it slows it down?  I have 5 keys in total I'm trying to block.  Doesn't seem like much.

2. Also, tt seems the code will keep progressing along before all keys are blocked.
Is there any way to get an option like in other functions where it won't continue until all keys are blocked?

Can anyone who knows the code well enough of Voice Attack confirm how it operates?
Will it indeed move to the next line in the code even if all keys are not confirmed blocked yet?

[Pfeil]

What result are you trying to achieve?

Does your loop contain any other actions?

[Starblue7]

What result are you trying to achieve?

Does your loop contain any other actions?

Code: [Select]

    Begin Device State Check :  Keyboard Key 'F1' Is Pressed
        Block specific keyboard keys  (F1)

I want to achieve a way to lock down a key immediately after its keypress is detected in the loop, so as any subsequent keypress of the same key will be unrecognized.

I've read that in the Block/Unblock keys command it is advised to put a pause of .05ms after the command in order to give it time to process the blocking state of those keys.
That's fine internally for Voice Attack (maybe) and any loop processing, however, that doesn't help if a user quickly presses the key again and a result is registered downstream in the target game.

Other than any other suggestion you have to decrease the amount of time it takes for Voice Attack to actually block subsequent keypresses at risk of the target game getting one prior to the block on a quick re-press by the user, I'm left thinking that the below idea would be better:

- Create an initial instruction in the command's (one with the loop) initial trigger to at initial load to block the keys.
One time only.

This so that, the subsequent polling loop in the command will ALREADY have those keys blocked so there'd be no chance for the user to accidently or purposely get that keypress sent down to the game.

I'm just wondering how Voice Attack can/will/should unblock those when the target game looses focus.
I.e. the command may stop running and may resume on refocus, but the keys will still remain blocked.
I need to figure out a smooth when for those keys to be unblocked when switching out of the application and reblocked when returning.

hmmmm....

[Starblue7]

...  I guess the above won't work ...

I was hoping that even though I blocked the keypress by the user, Voice Attack would STILL be able to send a keypress to the game within the command....

i.e.  The Enter Key is blocked from the user doing anything, but if they hit it and it's recognized in the loop in Voice Attack, then Voice Attack will send ONE Enter Keypress to the game at the appropriate time.

Unless there's some setting somewhere I'm missing, I can't send a keypress from Voice Attack to the Game even though VA blocked it from the user's end, it's blocked even for VA.

[Gary]

I was hoping that even though I blocked the keypress by the user, Voice Attack would STILL be able to send a keypress to the game within the command....

I have a command that does the following actions:

Code: [Select]

Block specific keyboard keys (blocks alpha Enter key)
Pause 5 seconds
Quick Input, 'Hello'
Press Enter key and hold for 0.1 seconds and release
Pause 5 seconds
Unblock specific keyboard keys (unblocks alpha Enter key)
If I target Notepad, start pressing Enter over and over (spamming quickly) and execute that command, the alpha Enter key immediately stops responding.  After five seconds, 'Hello' is typed out on a single line, followed by a single Enter key while my physical key presses are still not registered.  After another five seconds, my key alpha Enter key is registered again. 

It's been this way for a number of years (I used it a lot in World of Warcraft), and I haven't had any feedback that has indicated that it wasn't working as expected.  What does your command look like?

[Starblue7]

I was hoping that even though I blocked the keypress by the user, Voice Attack would STILL be able to send a keypress to the game within the command....

I have a command that does the following actions:

Code: [Select]

Block specific keyboard keys (blocks alpha Enter key)
Pause 5 seconds
Quick Input, 'Hello'
Press Enter key and hold for 0.1 seconds and release
Pause 5 seconds
Unblock specific keyboard keys (unblocks alpha Enter key)
If I target Notepad, start pressing Enter over and over (spamming quickly) and execute that command, the alpha Enter key immediately stops responding.  After five seconds, 'Hello' is typed out on a single line, followed by a single Enter key while my physical key presses are still not registered.  After another five seconds, my key alpha Enter key is registered again. 

It's been this way for a number of years (I used it a lot in World of Warcraft), and I haven't had any feedback that has indicated that it wasn't working as expected.  What does your command look like?

Gary.

Thanks for your response.

Well, certainly no, I wouldn't say this activity is the norm per say.
However, in my testing I did notice that for me and Star Citizen, when selecting keys like F1, F11, F2 (which all pull up graphical menus which include character animation, and relatively inconsistent timings, there's more likely a chance for things getting out of sync.

This is why in another thread I put forth a suggestion about how the Block Keys operate in VA.
https://forum.voiceattack.com/smf/index.php?topic=1228.0

At this point, I've moved out my code from the polling command to it's own command and locked the key.
[Do not allow key to be passed through]  i.e. [ENTER] Key
This now works more reliably enough,

HOWEVER..

When I switch out of the game to let's say here, or notepad, the [ENTER] key is still locked.
The command has all the below checked:
[Allow other commands to be executed while this one is running]
[Always execute this command]
[Stop command if target window focus is lost]   <-----   Should release Enter key, no?
[Resume command if focus is regained]

My apologies if the above is BASIC..  But now don't know why when switching out of the focused game application, why VA also doesn't release the ENTER key for use?

Thanks much in advance for correcting my potentially amateur error above.   

[Pfeil]

The "Do not allow key to be passed through" option is not affected by command targeting, I.E. it always blocks the keypress as long as keyboard shortcuts are enabled (they are automatically disabled when certain VoiceAttack windows are open), regardless of which application has focus.

[Starblue7]

The "Do not allow key to be passed through" option is not affected by command targeting, I.E. it always blocks the keypress as long as keyboard shortcuts are enabled (they are automatically disabled when certain VoiceAttack windows are open), regardless of which application has focus.

I think that if the target application (either set at the command level or the profile level) focus is lost, then the LOCK of a keyboard command via the [Do not allow key to be passed through] should be released.
So as to ALT-TAB out to other applications and be able to use the key in those other applications.
Once the target application regains focus, then lock will be respected.

Does it work that way and I'm doing something wrong?

[Gary]

I think that if the target application (either set at the command level or the profile level) focus is lost, then the LOCK of a keyboard command via the [Do not allow key to be passed through] should be released.

VA does not do that currently.  However, something like that could be added as an option on the command screen where it would be presented as, 'Do not invoke this command unless the target is in focus', where VA will completely disregard the trigger (voice, keyboard, mouse, joystick, external) as well as not block (handle) the key/mouse press.

I'm working on a set of new features atm, but I'll definitely add it to the research list.

[Gary]

Actually, now that I'm thinking about it, it might not be possible for the keys to not be 'handled' (blocked) in that circumstance.  The problem is that the keyboard triggers for commands will handle (block) BOTH the key down event as well as the key up event, whether the trigger is set for key down only or key up only (this is by design and is expected behavior).  This could cause key presses to get out of sync (key is pressed down, but key up event is blocked) or require some ungodly amount of processing around every key down/up event while VA is active (not desirable as that can affect system performance while VA inspects keys, sees if key belongs to a command that requires focus then checks if the target is actually in focus before passing the message on to other apps (or not)).

[Starblue7]

Actually, now that I'm thinking about it, it might not be possible for the keys to not be 'handled' (blocked) in that circumstance.  The problem is that the keyboard triggers for commands will handle (block) BOTH the key down event as well as the key up event, whether the trigger is set for key down only or key up only (this is by design and is expected behavior).  This could cause key presses to get out of sync (key is pressed down, but key up event is blocked) or require some ungodly amount of processing around every key down/up event while VA is active (not desirable as that can affect system performance while VA inspects keys, sees if key belongs to a command that requires focus then checks if the target is actually in focus before passing the message on to other apps (or not)).

Thanks for considering it.

As of now, I'm handling it by checking within the command by {ACTIVEWINDOWTITLE} is indeed 'active' and in focus before I allow it to proceed with any keypress.  With the Command Shortcut = 'Do not allow key to be passed through'.

I don't know any other way of doing it without losing control of using those keys in other applications (that I ALT-TAB to) outside of the intended target game.

The issue is, the amount of time it takes to get back to a state where the intended window is recognized again by Voice Attack.  Within that amount of time, the user could potentially hit a key while in transition and the game sees it before Voice Attack has a chance to block it..

Hmm.