On Tue, 10 Apr 2007 11:05:16 -0700, Luc The Perverse
<sl***********************@cc.usu.eduwrote:
[...]
Two things. How am I supposed to test for normal codes like this?
It depends on what you want. The KeyDown event is particular to specific
physical keys on the keyboard. There's no "*" key per se...that's the 8
key with the SHIFT key held down (on a standard keyboard). So to detect
that you'd look for the "8" key, also checking the state of the SHIFT key.
Additionally, you shouldn't be casting the KeyValue property to a char,
because that's not what it is. Simply use the values from the enumeration
in your switch statement. In other words, in your example you'd use
Keys.X and Keys.D8 for the case statements, and in the Keys.D8 statement
you'd only execute the code if the KeyEventArgs.Shift property was true.
Alternatively, if all you really care about is truly the ASCII code
generated by the user, rather than the physical key being pressed, handle
the KeyPress event instead. That does give you the final ASCII code that
results from the keyboard input and you don't have to mess with the
parsing the key+modifier combinations yourself.
Is there a way to capture things for the entire form without making a
KeyDown handler for every item in the form?
As the documentation points out:
To handle keyboard events only at the form level and not
enable other controls to receive keyboard events, set
the KeyPressEventArgs.Handled property in your form's
KeyPress event-handling method to true
In other words, handle the event in the form and mark it as handled so
that it doesn't propogate down to the child controls.
The same thing applies for the KeyDown and KeyUp events, except those of
course use the KeyEventArgs class instead of KeyPressEventArgs class.
Pete