`sendKeyStroke` has varying results if num lock is on or not

Issue Description:

sendKeyStroke functions differently depending on if the user has num lock enabled or disabled. If num lock is disabled, the key strokes seem to act appropriately. But if num lock is enabled, the function sends unexpected keys.

For reference, our app is sending home, delete, up, and down key strokes[1]. If the user has num lock enabled then instead of the expected results we see a series of numbers and decimals, as if the user was pressing a corresponding key on the numpad.

[1] I wasn’t able to find documentation on the accepted input for the keyString parameter, so if these values are unexpected please let us know.

Steps to reproduce:

Call sendKeyStroke("up") with num lock disabled, and observe the expected results. Enable num and observe that OW sends an 8 keystroke instead.

Impact for my app: [low, mid, high, show-stopper]

Low - users can work around the issue by disabling num lock, it’s just an inconvenience.

@bryan thanks for the info. We will check it out and update you.

hi @bryan,

We had some issues with this API on previous versions. We released a fixed in OW version 138.

Can you please make sure that you are using the latest version of OW client? You can download the developer’s version (which is 139v), try and update us.

@bryan ok I test it now (on version 139, but it should work on previous versions as well) - and it’s working as expected:

When I call sendKeyStroke("up") the function always forwards it as up arrow, regardless of the num lock state.

BTW, the valid values for this function are the same as the Microsoft Key enum. (I will add it to the docs).

Thanks.

Hey @eransharv , thanks for looking into the issue.

BTW, the valid values for this function are the same as the Microsoft Key enum. (I will add it to the docs).

Thanks! I’ve updated our implementation to use the correct casing for the keyString parameter.

Can you please make sure that you are using the latest version of OW client?

Sorry for not including my OW client version in my original post. I was testing on originally on version 137 but have updated to 139 to re-test.[1] After updating to 139, I’m still seeing the original issue if numlock is enabled on my keyboard.

In our use case, we’re attempting to send multiple sendKeyStroke events in quick succession:
["Up", "Up", "Up", "Home", "Shift+End", "Delete", "N", "A", "M", "E", "Down", "Home", "Shift+End", "Delete", "P", "A", "S", "S"]
with the expectation that the in-game text fields will be auto-filled.

But if numlock is enabled then we’re seeing the following results:


where it appears that the following keystroke events are being mapped:

{"Up" '8'
"Home" '7'
"Shift+End" '1'
"Delete" '.'}

Is there any more information you can think of that might be helpful so that we’re seeing the same results?
We’re seeing the issue consistently here, and have seen our beta users also experiencing the issue.

[1] Not sure if this is expected, but I had to uninstall/reinstall the OW client to get the updates.
Using the “Check for Updates” button in-client kept saying I was on the latest version at 137,
even after a restart.

@bryan

  1. Can you clarify what exactly is the “Up Up Up…”? 2. When you press the above keys manually, is it working as expected?
  2. When you press the series of keys manually, it’s working as expected?
  3. Did you try to “insert” some delay between the keystrokes? (I want to eliminate the suspicion that there is an issue when you auto-enter couple of chars in a row).
  1. Can you clarify what exactly is the “Up Up Up…”?

That’s the series of keystrokes that we’re attempting to send when the user presses “Auto-Fill”. Each string is a separate call to sendKeyStroke with the corresponding string.

sendKeyStroke("Up");
sendKeyStroke("Up");
sendKeyStroke("Up");
...
  1. When you press the series of keys manually, it’s working as expected?

Yes, manually entering the same keystrokes works as expected, with and without numlock enabled.

  1. Did you try to “insert” some delay between the keystrokes?

Just gave that a try and seeing the same results. Even calling a single sendKeyStroke("Up") is showing a '8' character.

@bryan I’m passing it to our QA and i will update. thanks