It's not wxTextCtrl doing this. However, this does point out the Windows-
centricity of wxWindows.
What you're seeing is the way Windows normally handles characters. The
WM_KEYDOWN and WM_KEYUP messages, which are used in the wxKeyEvents demo, get
relatively raw keycodes: the 'x' key plus an indicator for the control key.
When the standard window procedure sees a WM_KEYDOWN event that is not
otherwise suppressed, it translates these raw keycodes to ASCII and sends the
ASCII in a WM_CHAR message. That's what you're seeing. Ctrl-X is ASCII 24,
ctrl-V is ASCII 22.
ยทยทยท
On Mon, 13 Jan 2003 15:57:02 -0500, Will Sadkin <wsadkin@nameconnector.com> wrote:
I've actually figured out how to do this through my own
experimentation, by placing an OnChar() handler in my derived
class in addition to my validator. (If I don't, the cut and
paste operations get completed *prior* to validator firing,
producing unacceptable results.)However, my experiments lead to a couple of mysteries that
I was wondering if any wxPyrt could illuminate:The keycodes returned to a wxTextCtrl's EVT_CHAR routine for
Ctrl-X and Ctrl-V are 24 (CAN) and 22 (SYN) respectively.This contrasts with the "wxKeyEvents" demo, in which the
control key event is separately fired (possibly multiple times,
if held down for a while) followed by the eventual 'x' or
'v' key event. With a wxTextCtrl (at least under MSW),
all you get is the one (1) key event for the lot.There is nothing in the documentation I can find that discusses
this translating behavior of the wxTextCtrl, ...
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.