|
From: Kevin A. <al...@se...> - 2001-10-06 20:03:24
|
Based on a recent discussion on the wx-dev mailing list, the addition of the
key handlers may cause a problem under wxGTK. There may be additional issues
with differences in key codes generated. Please report any issues you find
to the list.
The key events which were defined back in July and added to spec.py, never
got added to the TextField, PasswordField, and TextArea class event
bindings. There was a problem with passing the event on (wxPython
Event.Skip()) if the user code didn't process the event. Anyway, I want to
finally solve the issue, so I've checked in changes to:
event.py, widget.py, and wxPython_binding.py
There will probably be a change to dispatch.py as well. The current changes
don't do much except allow the user code to handle the event and display the
event in the Message Watcher. I still need to add support for not passing on
the keyPress event, which will be necessary to limit the valid keystrokes
for a field. For example, if you only wanted a user to enter numbers you
would define a on_fieldName_keyPress handler that only called skip() when
the key code was 0 through 9.
The order of events:
keyDown, keyPress, textUpdate, keyUp
Adding these events exposed some problems with the handling of tabs and the
return/enter key which I also need to investigate. However, it doesn't
appear that any of the samples have been broken by adding the key events. As
an example of handling each event, the following code could be added to
minimal.py:
def on_field1_keyDown(self, target, event):
print 'field1_keyDown'
def on_field1_keyPress(self, target, event):
print 'field1_keyPressed'
#event.skip()
def on_field1_keyUp(self, target, event):
print 'field1_keyUp'
Note that the 'event.skip()' line commented out above will need to be
uncommented in the future or the keyPress handler above would keep the
characters from showing up in the field as user typed them.
In order to do anything with the event right now you need to get the native
wxPython event and then use wxPython methods.
def on_field1_keyPress(self, target, event):
print 'field1_keyPressed'
nEvent = event.getNativeEvent()
print nEvent.GetKeyCode()
#event.skip()
See wxKeyEvent and the Keycodes topics in the wxWindows/wxPython
documentation for more info; I've included the Keycodes topic below. We'll
have to define our own method wrappers and keycode constants in order to
duplicate the wxPython functionality.
I am thinking about just duplicating the codes below, but using a KEY_
prefix instead of WXK_ prefix; the constants will be put in a separate
module file to make it easy to reference them. I'll need some suggestions
for whether we need to do anything specific for supporting Unicode or
keyboards outside the USA generating different 8-bit ASCII key codes
(Russian, Swedish, etc.)
It would be helpful to have some suggestions for a sample or two that need
to do key processing to get a better idea of the functionality we need to
support.
ka
---
Keycodes
Keypresses are represented by an enumerated type, wxKeyCode. The possible
values are the ASCII character codes, plus the following:
WXK_BACK = 8
WXK_TAB = 9
WXK_RETURN = 13
WXK_ESCAPE = 27
WXK_SPACE = 32
WXK_DELETE = 127
WXK_START = 300
WXK_LBUTTON
WXK_RBUTTON
WXK_CANCEL
WXK_MBUTTON
WXK_CLEAR
WXK_SHIFT
WXK_CONTROL
WXK_MENU
WXK_PAUSE
WXK_CAPITAL
WXK_PRIOR
WXK_NEXT
WXK_END
WXK_HOME
WXK_LEFT
WXK_UP
WXK_RIGHT
WXK_DOWN
WXK_SELECT
WXK_PRINT
WXK_EXECUTE
WXK_SNAPSHOT
WXK_INSERT
WXK_HELP
WXK_NUMPAD0
WXK_NUMPAD1
WXK_NUMPAD2
WXK_NUMPAD3
WXK_NUMPAD4
WXK_NUMPAD5
WXK_NUMPAD6
WXK_NUMPAD7
WXK_NUMPAD8
WXK_NUMPAD9
WXK_MULTIPLY
WXK_ADD
WXK_SEPARATOR
WXK_SUBTRACT
WXK_DECIMAL
WXK_DIVIDE
WXK_F1
WXK_F2
WXK_F3
WXK_F4
WXK_F5
WXK_F6
WXK_F7
WXK_F8
WXK_F9
WXK_F10
WXK_F11
WXK_F12
WXK_F13
WXK_F14
WXK_F15
WXK_F16
WXK_F17
WXK_F18
WXK_F19
WXK_F20
WXK_F21
WXK_F22
WXK_F23
WXK_F24
WXK_NUMLOCK
WXK_SCROLL
|