Numpad utilization

General Discussion
1

Greetings forum goers,

I’ve been poking around for a week or so trying to decide if I want to use Panda3d or Ogre as a game engine for a project I’ve had in my mind for over a year, but haven’t had the time/inclination to actual go about creating it. I started piddling around with Panda yesterday by editing the samples when I ran across a disheartening disability within the core of Panda’s abilities.

As the subject may have given it away… There is no distinction between numeric keypad entry and standard qwerty numeric input (that I’m currently aware of). It doesn’t seem like this would be terribly hard to implement beings that they send different key codes when used. Either I have made a grave oversight or (in my opinion) the functionality of Panda’s keyboard input system is at a disadvantage.

I’ve searched the forums, but nothing of value was found. Does anyone know of a work-around for this? I want the normal keyboard numbers to be used for a macro system, the numpad to be used for character movement, and the arrows for camera orbit.

Is there a way to hi-jack the iostream and extrapolate a new data reference for numpad input?

I apologize that my first post is of such a seemingly negative attitude toward Panda. :cry:

2

I assume you mean in Windows? We use MapVirtualKey() to interpret the keycode on Windows, and that function does indeed collapse the distinction between the numeric keypad and the primary number buttons. :frowning:

One obvious workaround is just to press the “num lock” key, which turns the numeric keypad into the arrow keys.

We have talked about reworking the keyboard handling for a future release of Panda, for reasons such as this. It wouldn’t be hard to put a bit of custom code in yourself, if all you wanted was to add some code to intercept the numeric keypad before it went through MapVirtualKey().

Of course, not all keyboards even have a numeric keypad (particularly not laptops), so depending on the range of hardware you want to make your application available to, you might want to consider your keyboard design carefully. :wink:

David

3

Is there any documentation on MapVirtualKey()?

The only reference I found from a forum search was [url]Getting non-ascii character events]

The documentation search came up with nothing.

4

It’s a Windows function, not a Panda function: http://msdn.microsoft.com/en-us/library/ms646306(VS.85).aspx

5

Mmmm… I may be under the false assumption that we were both talking about a workaround within Panda itself and not writing a custom IO script for Panda.

6

I was talking about making a change within Panda. In panda/src/windisplay/winGraphicsWindow.cxx, you can find the call to MapVirtualKey(). Before this call you can see a special-case handling of a number of special keys like F1 etc. It would be easy to add all of the numeric keypad keys to this special-case list.

But, really, is it so bad to press the num lock key?

David

7

The controls would use almost all of the numpad actually. With the ability to bind literally anything across the keyboard to other functions as well. Thanks for pointing me in the right direction.

8

Nothing has to be changed within ButtonHandle or KeyboardButton?

Edit: I did a search for them and found the ButtonRegistry section.

Am I correct in assuming that making special cases before MapVirtualKey() and then making register_button calls within KeyboardButton.cxx/KeyboardButton.h will suffice?

Sorry if I’m coming off as a newbie. I haven’t tackled a substantial coding endeavour since I was a CSC major in 2005… I’m fairly rusty, but it’s coming back.

9

Sure, that would be fine.

David

10

That worked all except the “numpad_enter” case, but I’m going to rebuild without it and just allow Return and Enter to have the same functionality.

Thank you again for your assistance in this matter.

That being my only “problem” with Panda, I hope that this is the beginning of a beautiful friendship.

11

Sorry to revive a solved issue thread, but now I have run into a new problem concerning numpad keyboard input.

The numpad input is completely functional when used alone, but I did not anticipate “self.accept(shift-numpad_#, )” to be a problem.

Would you(David) or anyone else be able to point me in the right direction as to where I might be able to implement this within the source code?

12

What is the nature of the problem with the shifted keys?

David

13

I can accept normal shifted keys, but when I try to use the shift with the numpad keys that I enabled they do not work.

self.accept(“shift-0”, ) works, but…
self.accept(“shift-numpad_0”, ) does nothing

I tried to be lazy and just write up a quick work around, something like…

self.accept("numpad_0", <function1>)
self.accept("shift", self.shiftDown)
self.accept("shift-up", self.shiftUp)


...


def shiftDown(self):
       self.accept("numpad_0", <function2>)

def shiftUp(self):
       self.accept("numpad_0", <function1>)

… but alas it did not work either.

14

The easiest way to diagnose this is to enable verbose message logging with base.toggleVerbose(). Then press some keys and see what messages are actually generated. For instance, when you press shift-0 you should able to see the ‘shift-0’ event generated. Then check to see what is actually generated when you press shift-numpad_0.

Seeing the actual message generated should give you some insight.

David

15

I wasn’t sure why it was giving me seemingly random inputs with verbose messaging on, but I looked at my keyboard and figured out what it is doing.

shift-numpad_0 = insert
shift-numpad_1 = end
shift-numpad_3 = page_down
shift-numpad_7 = home
shift-numpad_9 = page_up
shift-numpad_period = delete
shift-numpad_2,4,8,6 = arrow keys

All of which are the alternate uses of the numpad keys.

Would there be a way around this?

16

That sounds like it might be the work of MapVirtualKey() again. I’m pretty sure Panda wouldn’t do anything like that.

To research this further, you’ll probably need to see what windows key number is being generated in the WinGraphicsWindow event handler.

david

17

Would activating

if (windisplay_cat.is_debug()) {
      windisplay_cat.debug()
        << "keydown: " << wparam << " (" << lookup_key(wparam) << ")\n";
    }

within WinGraphicsWindow::window_proc/case WM_KEYDOWN: do the trick?

If so, how is this done?

Edit: The “trick” of showing what windows key numbers are being generated that is…

18

Sounds reasonable. Put:

notify-level-windisplay debug

in your Config.prc file to active this debug output.

David

19

Sorry for the horrible delay, but my personal life took a few unexpected turns so I had literally zero time for playing with Panda…

I finally got around to setting it to debug mode.

Results:

(Shift + numpad_4)
keydown: 16 (shift)
keydown: 16 (shift)
keydown: 16 (shift)
keydown: 16 (shift)
keyup: 16 (shift)
keydown: 37 (arrow_left)
keyup: 37 (arrow_left)
keydown: 16 (shift)
keyup: 16 (shift)

It appears as though it is simulating a shift-up only with the numpad keys.

(Example with shift + t)

keydown: 16 (shift)
keydown: 16 (shift)
keydown: 16 (shift)
keydown: 84 (t)
keyup: 84 (t)
keyup: 16 (shift)

Any suggestions for a possible workaround?