Robin answered a question on this in 2000. Is the answer (the public data members of**
wxKeyEvent and wxMouseEvent) aren’t currently exposed to wxPython)** still the same in 2009?? Wow!, Robin has been so helpful for so many years. Many thanks.
Markandeya
Answer by Robin Dunn
Sep 08, 2000;
Suposse i want to imitate the sending of a keystroke to a text
control. I would like to say something like SendKey(txtCtrl, keyCode=48, altDown=0, shitDown=0 ,…)
As was mentioned you can do
wxPostEvent(window.GetEventHandler(), event)
and the event will be sent to the window in idle time, or you can do
window.GetEventHandler().ProcessEvent(event)
and the event will be processed immediately. There are some complications
though… As mentioned in the last message the public data members of****wxKeyEvent (and wxMouseEvent) aren’t currently exposed to wxPython, only the
methods.
Also, for some (most?) event types artificially generating and sending an
event won’t actually effect the window. You’ll be able to test your event
handlers, but the default behaviour won’t happen. For an example look at
what happens when a key event happens naturally on MSW:
Windows sends a WM_CHAR message to a wxWindow
the wxWindow catches the message and turns it into a wxKeyEvent
the event is sent with GetEventHandler()->ProcessEvent(event) which looks
for an event handler bound with EVT_CHAR
if the event was not caught or the handler called event.Skip() then the
original message is passed on to the window’s default WndProc where is does
things like adding a character to a text control
When you artificially generate and send an event you can simulate up to #3,
but when ProcessEvent returns there is no way to send the message on to the
window for default processing. Even if there was a way it would be
Robin answered a question on this in 2000. Is the answer (_*the public data members of *__*
wxKeyEvent and wxMouseEvent) aren't currently exposed to wxPython) *_still the same in 2009?? Wow!, Robin has been so helpful for so many years. Many thanks.
Markandeya
Answer by Robin Dunn <http://www.nabble.com/user/UserProfile.jtp?user=238821> Sep 08, 2000;
Suposse i want to imitate the *sending* of a *keystroke* to a text
> control. I would like to say something like
> *SendKey*(txtCtrl, keyCode=48, altDown=0, shitDown=0 ,...)
My standard procedure upon finding a solution on the web is to try it and see if it works. If it doesn't and I can't find anything newer, THEN I post a question. You should give this a spin and see if it works. Note though that "shitDown" is probably supposed to be "shiftDown"...
As was mentioned you can do
wxPostEvent(window.GetEventHandler(), event)
and the event will be sent to the window in idle time, or you can do
window.GetEventHandler().ProcessEvent(event)
and the event will be processed immediately. There are some complications
though... _* As mentioned in the last message the public data members of *__*
wxKeyEvent (and wxMouseEvent) aren't currently exposed to wxPython, only the
methods. *_
Also, for some (most?) event types artificially generating and *sending* an
event won't actually effect the window. You'll be able to test your event
handlers, but the default behaviour won't happen. For an example look at
what happens when a key event happens naturally on MSW:
1. Windows *sends* a WM_CHAR message to a wxWindow
2. the wxWindow catches the message and turns it into a wxKeyEvent
3. the event is sent with GetEventHandler()->ProcessEvent(event) which looks
for an event handler bound with EVT_CHAR
4. if the event was not caught or the handler called event.Skip() then the
original message is passed on to the window's default WndProc where is does
things like adding a character to a text control
When you artificially generate and *send* an event you can simulate up to #3,
but when ProcessEvent returns there is no way to *send* the message on to the
window for default processing. Even if there was a way it would be
drastically
different on different platforms.
Events sent programmatically are different than those sent by the mouse/keyboard. You'll want to search the archives for the technical details of how they differ as I don't remember them that well.
Robin answered a question on this in 2000. Is the answer (_*the public data members of *__*
wxKeyEvent and wxMouseEvent) aren't currently exposed to wxPython) *_still the same in 2009??
No, you do have access to those public data members now.
But the rest of the answer is still true. An unhandled artificial event is still not converted to a native event and forwarded on to the native widget.
···
Wow!, Robin has been so helpful for so many years. Many thanks.
Markandeya
Answer by Robin Dunn <http://www.nabble.com/user/UserProfile.jtp?user=238821> Sep 08, 2000;
Suposse i want to imitate the *sending* of a *keystroke* to a text
control. I would like to say something like
*SendKey*(txtCtrl, keyCode=48, altDown=0, shitDown=0 ,...)
As was mentioned you can do
wxPostEvent(window.GetEventHandler(), event)
and the event will be sent to the window in idle time, or you can do
window.GetEventHandler().ProcessEvent(event)
and the event will be processed immediately. There are some complications
though... _* As mentioned in the last message the public data members of *__*
wxKeyEvent (and wxMouseEvent) aren't currently exposed to wxPython, only the
methods. *_
Also, for some (most?) event types artificially generating and *sending* an
event won't actually effect the window. You'll be able to test your event
handlers, but the default behaviour won't happen. For an example look at
what happens when a key event happens naturally on MSW:
1. Windows *sends* a WM_CHAR message to a wxWindow
2. the wxWindow catches the message and turns it into a wxKeyEvent
3. the event is sent with GetEventHandler()->ProcessEvent(event) which looks
for an event handler bound with EVT_CHAR
4. if the event was not caught or the handler called event.Skip() then the
original message is passed on to the window's default WndProc where is does
things like adding a character to a text control
When you artificially generate and *send* an event you can simulate up to #3,
but when ProcessEvent returns there is no way to *send* the message on to the
window for default processing. Even if there was a way it would be
drastically
different on different platforms.