Numeric keypad, how to filter pressed keys?

amorosik

Member
Local time
Today, 11:04
Joined
Apr 18, 2020
Messages
518
A fairly frequent request, for users who often use the numeric keypad, is to make the program code always 'see' the same key
Regardless of the state of the Num-Lock and the type of keyboard
And so when the operator presses the '4' key on the numeric keypad (the 4 key is the combination of both the number 4 and the left-arrow), the program must 'see' it always as the number 4 and never as the left-arrow
I tried to use the form keydown event to check the incoming keycode (keypreview=true) and change it if necessary
So that the '4' key would always arrive on the form, even if I pressed the num-lock
But I see that using different keyboards, different codes come in

So the question is: what do you think is the best way to make the code always see the same key, for example the number 4, when the key with the number 4 is pressed, even using different keyboards?
 
I suspect the real issue to be solved here is knowing what key the user wanted to press.
How would you distinguish between PG-UP, PG-DN or Home (as examples) as normal key presses and the number pad versions?
 
What I would like to do is intercept the pressure of the numeric keypad keys and return only the numeric part to the program
And therefore in the case of the number 4 key (the one that allows you to indicate both the number 4 and the left arrow) always return the number 4 to the program for subsequent processing
In your example the Pg-Up is together with the number 9, at the top right of the numeric keypad
Here in case the operator presses that key, the code must 'see' only the number 9, whatever the keyboard and whatever the state of NumBlock
 
I think you will struggle because the returned key code for any of the keys is the same regardless of which key is pressed.
So you are effectively going to remove the functions of the non-number pad keys on the normal keyboard.

As a test here are the returned keycodes when pressing the normal arrow keys (Down and Left) on my Keyboard
40
39
And here are the keycodes when pressing 2 and 6 on my number pad with the NumLock switched off
40
39

So, if you capture 40 and 39 and force them to be "2" and "6" as returned values you will disable the normal arrow keys permanently on that form, as well as any others you decide to force to the numbers. (Home, End, Ins, Del etc.)
This could make the form/application unusable.
 
Are you saying that it is not possible to distinguish the 'right arrow' pressed on the keypad (key with number 6 and right arrow, without NumLock) from the 'right arrow' of the 4 arrow key?
 
Access doesn't recognise any difference between the two, using the Keydown event property to return the keycode.
At least not on my system.

I use a Logitech Bluetooth K780 keyboard that has a number pad and the numbers in my post are copied and pasted from the immediate window.

The only way around the problem I can think of, would be to ensure that NumLock is on when loading the form, but that doesn't stop someone from turning it back off again. I also don't know how you would check for that and enforce it, or make it happen within Access.
 
Ok, i check the NumLock state and set on Form_Load

But if user change it?
Via vba there is way to 'hear' the event (NumLock change)?
 
Can't you just check it each time you want to capture the keypresses?
 
there is a 3rd party program that you can use to figgle with numlock. i forgot what it's called.
also volume.

it's free and works pretty well. i believe it's a exe with command line capabilities.

i know there are some sendkeys routines that disable numlock or toggle it - very annoying
 
If you have special requests, you should focus more on the operating system and the corresponding Win APIs. That's a bit more complex than a run-of-the-mill user development environment like Access with VBA.
 
Or better yet, combine the two
Common & effective
 
there is a 3rd party program that you can use to figgle with numlock. i forgot what it's called.
also volume.

it's free and works pretty well. i believe it's a exe with command line capabilities.

i know there are some sendkeys routines that disable numlock or toggle it - very annoying

Did you think that external exe is better than api function?
 
Did you think that external exe is better than api function?

Not better or worse, only complimented. Because in my case, and this was back in like 2011 so I can't remember which one, the API function that I called using VBA for whatever reason it always ended up fiddling with the user's numlock (undesired). I used a 3rd party thing to turn the num lock back on.
 
I think using vba + api's to mess with the key buffer sometimes unexpectedly messes up numlock state
 

Users who are viewing this thread

Back
Top Bottom