[prev in list] [next in list] [prev in thread] [next in thread]
List: vtk-developers
Subject: Re: [vtk-developers] vtkWidgetEventTranslator -- care and feeding?
From: "Karthik Krishnan" <karthik.krishnan () kitware ! com>
Date: 2007-12-20 17:19:35
Message-ID: 9ddb27260712200919x12acf20el566dc134a43c22ad () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 12/20/07, kent williams <nkwmailinglists@gmail.com> wrote:
>
> Hee. One last thing -- you Set a callback both for KeyPressEvent and
> CharEvent, and the result is hitting the Delete key once ends up
> deleting 2 points. The patch I sent commented out the second
> SetCallbackMethod, but you left both in.
Was there a reason to have a callback on both events? It doesn't
> appear to produce the behavior documented in Doxygen.
Ah yes.. Keeping the KeyPressEvent alone will suffice.
Funny, I didn't see the bug. If you ran your code on windows, you would've
noticed that only 1 point was deleted :)
So I asked myself, why are there two events,
vtkCommand::KeyPressEvent
vtkCommand::CharEvent
and why are they both emmitted.... After some snooping, here's why:
In windows, when a key is pressed, you get a WM_KEYDOWN message. You can get
access to the pressed key with its virtual key code.
Apart from this, as messages get translated by the TranslateMessage() Win32
function, they are checked with the current keyboard config, and an
additional WM_CHAR message is sent for each WM_KEYDOWN, with the
current-codepage character code of the key pressed.
Now, for ASCII characters like "a" etc, both events are emmitted. For the
special characters like "Delete", arrow keys etc, only the KeyPressEvent is
emmitted. The reason is that there is no alphanumeric character
representation of these keys.
The advantage that WM_CHAR gives that WM_KEYPRESS doesn't is the translation
of the message. So on non-US keyboards, representing accents etc, WM_CHAR
would provide the correct translation for accent keys etc, which WM_KEYPRESS
woundn't.... On mobile devices where there's more than one character mapped
to the same key, WM_CHAR would return the actual key press.
For non-windows people they shouldn't even bother about the CharEvent.
I guess the conclusion is that for all practical VTK purposes, its safe to
use the KeyPress event, unless somebody complains about it..
--
karthik
See :
http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_keydownwm_char-input-model/
[Attachment #5 (text/html)]
On 12/20/07, <b class="gmail_sendername">kent williams</b> <<a \
href="mailto:nkwmailinglists@gmail.com">nkwmailinglists@gmail.com</a>> \
wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> Hee. One last thing -- you Set a callback both for \
KeyPressEvent and<br>CharEvent, and the result is hitting the Delete key once ends \
up<br>deleting 2 points. The patch I sent commented out the \
second<br>SetCallbackMethod, but you left both in. </blockquote><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">Was there a reason to have a callback on both \
events? It doesn't<br>appear to produce the behavior documented in \
Doxygen. </blockquote><div><br><div><br>Ah yes.. Keeping the KeyPressEvent alone will \
suffice.<br> <br>
Funny, I didn't see the bug. If you ran your code on windows, you would've \
noticed that only 1 point was deleted :)<br><br>So I asked myself, why are there two \
events, <br> vtkCommand::KeyPressEvent<br> vtkCommand::CharEvent <br>and \
why are they both emmitted.... After some snooping, here's why:<br><br>In \
windows, when a key is pressed, you get a WM_KEYDOWN message. You can get access to \
the pressed key with its virtual key code. <br>Apart from this, as messages get \
translated by the TranslateMessage() Win32 function, they are checked with the \
current keyboard config, and an additional WM_CHAR message is sent for each \
WM_KEYDOWN, with the current-codepage character code of the key pressed.<br><br>Now, \
for ASCII characters like "a" etc, both events are emmitted. For the
special characters like "Delete", arrow keys etc, only the
KeyPressEvent is emmitted. The reason is that there is no alphanumeric
character representation of these keys.<br><br>The advantage that
WM_CHAR gives that WM_KEYPRESS doesn't is the translation of the
message. So on non-US keyboards, representing accents etc, WM_CHAR
would provide the correct translation for accent keys etc, which
WM_KEYPRESS woundn't.... On mobile devices where there's more than one
character mapped to the same key, WM_CHAR would return the actual key
press.<br><br>For non-windows people they shouldn't even bother about the \
CharEvent.<br> <br>
I guess the conclusion is that for all practical VTK purposes, its safe
to use the KeyPress event, unless somebody complains about it.. \
<br></div> <br>--<br></div>karthik<br><br>See : <a \
href="http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_keydownwm_char-input-mo \
del/">http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_keydownwm_char-input-model/
</a><br></div>
_______________________________________________
vtk-developers mailing list
vtk-developers@vtk.org
http://www.vtk.org/mailman/listinfo/vtk-developers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic