Scan keypad keys without Num-Lock?

Is it possible to scan the keypad keys with a standard Swing/Awt KeyListener derivation, no matter if Num_Lock is enabled or disabled?
Currently I fail with that: you’ve to press the Num-Lock key in order to be able to scan the keys with KeyEvent.VK_NUMPAD1…9 etc. If Num-Lock is disabled they keypad keys act as cursor keys/Pageup/down etc, which isn’t what I want to have.

A second question: if you want your overwritten keyPressed method to store any pressed key in a look-up table (array) is it OK to size that array at start-up time to the KeyEvent.KEY_LAST number? Or is this a “don’t do this ever” thing? :slight_smile:

So… is it not possible to distinguish between Keypad_4 and the left-arrow-key when Num-lock is disabled?
(With a KeyEvent being fired be the KeyListener.keyPressed() method)

The underlying OS can do this however, so it should be possible with Java, too. Probably I’m looking into the wrong method?

Actually, no, I don’t think this is possible with Java “raw”. KeyEvent abstracts the keyboard since the cursor left and the num-pad 4 might not be combined on some keyboards.

However, JInput could do this for you. But its quite an overhead to bring in for this…

Have you experimented with the KeyListener/KeyEvent stuff to see what you actually get?

Kev

[quote]Actually, no, I don’t think this is possible with Java “raw”. KeyEvent abstracts the keyboard since the cursor left and the num-pad 4 might not be combined on some keyboards.
[/quote]
I see. That’s a pity, but anway thanks for the info.

[quote]However, JInput could do this for you. But its quite an overhead to bring in for this…
[/quote]
Another native lib. Too much hassle actually - if avoidable.

[quote]Have you experimented with the KeyListener/KeyEvent stuff to see what you actually get?
[/quote]
Yes: with disabled num-lock key (the one with a yellow LED which is off now) I hit the keypad_4 key but get the KeyEvent.VK_LEFT, like if I had hit the left arrow key. :slight_smile: And so on.
With enabled num-lock key the keypad_4 reports the KeyEvent_VK_NUMPAD4 as expected.

Has this been your question or did I misunderstand you?

Anway, this is no WYSIWYG. It’s rather WYSIWYGBJWNE: What You See Is What You Get But Just With Numlock Enabled. :wink:

Are you sure that is the case? Because it really doesn’t make sense. An application should be able to receive events from both the keypad and arrow keys, regardless of numlock state.

According to the Javadocs, pressing numpad4 when numlock is off should result in VK_KP_LEFT, not VK_LEFT.

If that’s the case (and I’m willing to bet it is), just tie VK_KP_LEFT and VK_NUMPAD4 together. If you ever ever get either event, you know they’re generated from the same key.

EDIT: Ah, but then people are complaining that VK_LEFT is always returned, and never VK_KP_LEFT. Perhaps this is a lil bug in key events?

Coo, well that teaches me not read the docs!

Kev

[quote]Are you sure that is the case?
[/quote]
Yes. On my Win2000 with Java JRE v1.42_02-b03 it’s the case.

[quote]According to the Javadocs, pressing numpad4 when numlock is off should result in VK_KP_LEFT, not VK_LEFT.
[/quote]
Here it does result in VK_LEFT.
With numlock enabled, it results in VK_NUMPAD4.
The code VK_KP_LEFT I never receive.

[quote]EDIT: Ah, but then people are complaining that VK_LEFT is always returned, and never VK_KP_LEFT. Perhaps this is a lil bug in key events?
[/quote]
This I don’t understand I’m afraid… :slight_smile:

PS: Maybe some people could confirm their keypad’s keycode behaviour, please? (different JREs, maybe, different platforms?)

The code I use fo this is like the following, attached to a GLCanvas


myGLCanvas.addKeyListener(new Listentome());

...

class Listentome implements KeyListener
{
  public void keyPressed(KeyEvent eve)
  {
    int keycode = eve.getKeyCode();
    // keycode then is is VK_blabla
  }

Yeah, I always get VK_LEFT and not VK_KP_LEFT. Seems wrong to me. The javadocs say

That’s pretty clear IMO.

I’m using Sun’s java 1.4.2 for Windows.

The part you didn’t understand, I was just saying it looks like a bug.

It is a bug that will not be fixed… the work around is to use:getKeyLocation() on the KeyEvent.
It should return KEY_LOCATION_NUMPAD