WPF problem with KeyEventArgs

[Arne Garvander]

The code below does not work. When I enter a $ sign, e.Key = 'D4' !
private void item_KeyUp(object sender, KeyEventArgs e)
{
char dollar = '$';
if (e.Key.Equals( dollar))
{
find();
}
}
--
Arne Garvander
(I program VB.Net for fun and C# to get paid. When get paid, I laugh all the
way to the bank.)

[Peter Duniho]

On Fri, 01 May 2009 08:18:02 -0700, Arne Garvander
<ArneGa...@discussions.microsoft.com> wrote:

> The code below does not work. When I enter a $ sign, e.Key = 'D4' !

No, it doesn't. It equals Key.D4, which is very different from 'D4'
(which is an illegal character literal in C#).

> private void item_KeyUp(object sender, KeyEventArgs e)
> {
> char dollar = '$';
> if (e.Key.Equals( dollar))
> {
> find();
> }
> }

Handle the KeyPress event instead. KeyDown and KeyUp return specific
key/scan code data; that is, exactly which key was pressed. If you want
to know exactly which key was pressed, handle KeyDown and/or KeyUp. But
if you want to know what character was entered (as it appears you do
here), you need to handle KeyPress instead. That gives the final
character code after all the various input compositing has been done (e.g.
combining the key code with the Shift modifier key).

Pete

[WPF@discussions.microsoft.com Dr. WPF]

> Handle the KeyPress event instead. KeyDown and KeyUp return specific
> key/scan code data; that is, exactly which key was pressed.

I think you're talking about Windows Forms, Pete. There is no KeyPress
event in WPF. You also don't get scan codes in WPF key events.

[Peter Duniho]

Hmm. Well, I just assumed that since the KeyEventArgs class isn't
Forms-specific (it's in System.Windows.Input, not System.Windows.Forms),
that it was shared between Forms and WPF, and had the same semantics
wherever it was used.

I admit, I don't know enough about WPF to know why, if you "don't get scan
codes in WPF key events", the KeyEventArgs class would even be used.
Regardless, looks like this is a great example of why someone asking a
question should provide a concise-but-complete code example that reliably
demonstrates the problem. Otherwise, the guesswork required can really
confuse the issue.

That said, the OP never bothered to respond, so who knows if he even
bothered to come back and read the reply.

Pete

[Dr. WPF]

Agreed. The only thing in the post that indicated the OP was working with
the WPF version of KeyEventArgs was the title. They could have been much
clearer.

> Hmm. Well, I just assumed that since the KeyEventArgs class isn't
> Forms-specific (it's in System.Windows.Input, not System.Windows.Forms),
> that it was shared between Forms and WPF, and had the same semantics
> wherever it was used.

There are actually two very different KeyEventArgs classes, one in the Input
namespace and one in the Forms namespace. (This overlapping of class names
is pretty common between WPF and Windows Forms... especially in core areas
like input.)

A general rule is that if the namespace is System.Windows.Forms, then it is
WinForms specific, but if it is System.Windows.%AnythingElse%, then it is
WPF-specific. So the System.Windows.Input.KeyEventArgs class is WPF-specific.

> I admit, I don't know enough about WPF to know why, if you "don't get scan
> codes in WPF key events", the KeyEventArgs class would even be used.

The Key member of KeyEventArgs is used in other methods throughout the Input
namespace. It is simply an enum with friendly names for known keyboard keys.

There is a KeyInterop class with static methods that can be used to
translate a Key value to its Win32 virtual key and vice versa, but that is
about the extent of its usefulness.

There is no mechanism for translating a key event to its representative
character mapping (taking into consideration the current modifiers, etc).
Most input handling in WPF happens under the covers.

The KeyEventArgs class does have an internal member that identifies the scan
code, if someone cares to use reflection, but that comes with all the usual
warnings, of course. If someone really needs scan codes, they can process
input directly by specifying a handler for the InputManager's PreNotifyInput
and/or PostNotifyInput events.

This is an area where WPF could arguably be enhanced quite a bit. It would
be great to have a static interop method to which you could supply a
KeyEventArgs object and get back the simple char that results from the key
event and its currently active modifiers. Maybe we'll get something like that
in 4.0.

Cheers,
-dw