RE: [Pythoncard-users] keyDown, keyUp, and keyPress events

[Kevin A. <al...@se...>]

I've updated dispatch.py, event.py and wxPython_binding.py so that the
framework can tell if an Event was handled by user code. This means that if
you have a keyPress handler (none of the current samples use one) then you
must call event.skip() at the end of your handler or the character pressed
will not actually show up in the field. For example:

    def on_field1_keyPress(self, target, event):
        print 'field1_keyPressed'
        nEvent = event.getNativeEvent()
        print nEvent.GetKeyCode()
        event.skip()

Now that this change is in place, I'll start wrapping key code and modifier
keys, so we don't have to access the native wxPython event. I'm going to
check with Robin on the proper way to modify events or deal with
"intercepted" events for code where you want to change the behavior of a key
press such as automatically converting letters typed to uppercase.

Note that the current implementation is not equivalent to 'pass' in
HyperCard. Once other event issues are worked out, skip() may go away in
favor of calling a 'pass' equivalent that simply sends the message up the
hierarchy.

If you have no idea what I'm talking about, don't worry about it, since the
current change doesn't really break any current samples, you can ignore it
for now.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, October 06, 2001 1:06 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] keyDown, keyUp, and keyPress events
>
>
> 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
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>