Remember that there are differences between the
EVT_KEY_DOWN/UP events and the EVT_CHAR event. The former are
more or less raw hardware key events and the latter is cooked a bit.
(Well, "translated" is the term that is used.)
Also, if you catch hand handle a EVT_KEY_DOWN then there will be no
coresponding EVT_CHAR event because you've already done something
about the key.
try running the wxKeyEvents demo again and check the first
checkbox and clear the next two, so you're only looking at
EVT_CHAR events and I think you'll see something more like what
you expect.
Yep, you're right (of course :-), and looking carefully
at the code in that demo, I see that the values for control
characters are all consistent in a way I hadn't realized, ie.
they are the values you get if you add ord('A') to (keycode - 1).
(Now reading the wxKeyEvent documentation, this is described
there too.) So I'm assuming that this behavior will be
consistent on all platforms.
But why aren't there wx constants for these translated
keycodes? I understand that the list of current keycode
constants only includes the raw keycodes, but given that
"keycodes" are also what are retrievable inside OnChar
events, couldn't there be another set of cooked constants,
ie. WXK_CTRL_A, WXK_CTRL_B, etc. rather than either using
numeric constants or something like the math in the demo?
Remember that there are differences between the EVT_KEY_DOWN/UP events and the EVT_CHAR event. The former are more or less raw hardware key events and the latter is cooked a bit. (Well, "translated" is the term that is used.)
Also, if you catch hand handle a EVT_KEY_DOWN then there will be no coresponding EVT_CHAR event because you've already done something about the key.
try running the wxKeyEvents demo again and check the first checkbox and clear the next two, so you're only looking at EVT_CHAR events and I think you'll see something more like what you expect.
Yep, you're right (of course :-), and looking carefully
at the code in that demo, I see that the values for control
characters are all consistent in a way I hadn't realized, ie.
they are the values you get if you add ord('A') to (keycode - 1).
(Now reading the wxKeyEvent documentation, this is described
there too.) So I'm assuming that this behavior will be consistent on all platforms.
Yes, that's why I wrote that sample, to help pound wxMac into compliance.
But why aren't there wx constants for these translated keycodes? I understand that the list of current keycode constants only includes the raw keycodes, but given that "keycodes" are also what are retrievable inside OnChar events, couldn't there be another set of cooked constants, ie. WXK_CTRL_A, WXK_CTRL_B, etc. rather than either using numeric constants or something like the math in the demo?
There probably isn't a reason not to have them. It's probably just that most people are catching them in a keydown handler and checking for the C++ equivallent of evt.ControlDown() and evt.GetKeyCode == ord('A').
ยทยทยท
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
