Not all keyboard buttons generate an event

[Mike]

Buttons like ÖÄÜ etc do not trigger any of the events accepted with the functions(only setKeystrokeEvent works) below:
base.buttonThrowers[0].node().setButtonDownEvent('bdown')
base.buttonThrowers[0].node().setButtonUpEvent('bup')
base.buttonThrowers[0].node().setButtonRepeatEvent('repeated')

Testmachine is Windows XP p3d 1.8.0

It should be fixed sine 2009 / 1.7.0 (see: http://www.panda3d.org/forums/viewtopic.php?t=7888&highlight=setkeystrokeevent) but it seem it isn't.

##================
# -*- coding: cp1252 -*-
import sys

from direct.showbase.DirectObject import DirectObject
from panda3d import direct
from panda3d.core import ButtonThrower
from panda3d.core import TextNode
from panda3d.core import CardMaker

from direct.directbase import DirectStart

class Keys(DirectObject):
    def __init__(self):
        base.buttonThrowers[0].node().setButtonDownEvent('bdown')
        base.buttonThrowers[0].node().setButtonUpEvent('bup')
        base.buttonThrowers[0].node().setKeystrokeEvent('stroked')
        base.buttonThrowers[0].node().setButtonRepeatEvent('repeated')

        self.accept('stroked', self.buttons,['stroked'])
        self.accept('bup', self.buttons,['bup'])
        self.accept('bdown', self.buttons,['bdown'])
        self.accept('repeated', self.buttons,['repeated'])

        #text
        self.mes=TextNode('mes')
        self.mes.setAlign(TextNode.ACenter)
        self.mes.setText('press alt+f4 to exit')
        self.textnode=aspect2d.attachNewNode(self.mes)
        self.textnode.setScale(0.1)

    def buttons(self,tag,but):
        out = but
        out = out.encode("utf8")
        print("type(tag)={0}, type(but)={1}".format(type(tag),type(but)))
        print("tag={0}".format(tag))
        print("but:",but, "out:",out)
        self.mes.setText(out)

        if but=='escape':
            sys.exit()

k=Keys()
run()

[Mike (revington)]

I did dig through the c++ codebase and found why not all keys generate events.

Panda only registers buttonhandles for chars in range from 32 to 126(US-ASCII) in keyboardButton.cxx, line 173.
And panda uses char instead of unsigned char(which would be needed for iso 8859-1 to 8859-15).

Basically all it would take is use unsigned char and extend the range to 255 in the mentioned loop in keyboardButton.cxx

Sorry that I can't help more, maybe someone whith more knowledge of c++ can implement these(or similar) changes.

With the support for Code point (0-255) most of europes charsets would be covered, see:
http://en.wikipedia.org/wiki/ISO/IEC_8859

[Mike (revington)]

Also in buttonRegistry.cxx all char references needs to be unsigned etc and in ButtonRegistry::
ButtonRegistry() we need to reserve space for all 255 uchars I guess.

[rdb (rdb)]

I don't think it's that easy, support would need to be added in the OS-specific display modules that generate these keyboard presses in the first place as well.

[Mike (revington)]

Yeah, in winGraphicsWindow.cxx is a call to isascii which would also need to be changed, because panda discards all keys that are outside the 7bit ascii range.

Imho the result from MapVirtualKey should just be checked if its in range 32 - 255 and then call KeyboardButton::ascii_key as it does today(but unfortunately only for 7bit ascii chars).

But you are right rdb, I guess there are more places in the code I didn't check and would need to be changed, for example on Linux all handled chars are hardcoded in x11GraphicsWindow::
map_button.

[rdb (rdb)]

I'm not quite sure whether going forward we need to start adding all these letters. It's a bit of a slippery slope: sure we can add "ë" and "я", but then why not add every unicode character that can be produced by any keyboard layout? What if someone comes up with a 20-layer Chinese keyboard layout? What about all the emoji buttons on mobile virtual keyboards?

Obviously, keypress events should not be used for text input, and most keyboards don't *have* these keys, so I don't really see the value of adding these event names. The new "raw buttons" in 1.9 resolve the problem nicely of being able to bind the keys in a layout-agnostic way, and get_keyboard_map() can be used to figure out how the keys are mapped for presenting the name of the key to the user.

So I'm going to mark this as Won't Fix for now, until someone can give me a really compelling argument for why we need to add more button handles.

(Although in a way, the way the bug title is worded, it *is* fixed - all keyboard buttons now do generate an event, prefixed by "raw".)