Get the char on Control.KeyDown?

问题:

When handling Control.OnKeyPress event, there is a KeyPressEventArgs that contains a KeyChar.

For usability reasons I need exactly the same KeyChar but when handling OnKeyDown event.

The KeyEventArgs does not contains any char related data. I mean, if press the A key with or without Shift its not affecting the KeyCode, KeyData or KeyValue. The same when using another language, i still getting capital english values.

How to get a KeyPressEventArgs.KeyChar inside KeyDown event?

Thanks.

回答1:

Convert it. Here is simple function for converting 'A' to 'a'. It converts only capital chars from [A-Z] set. The value 32 is diff between 'A' and 'a'.. Sure you can extend it to your requirements, or ask for feature here.

char getChar( KeyEventArgs e )
{
 int keyValue = e.KeyValue;
 if ( !e.Shift && keyValue >= (int) Keys.A && keyValue <= (int) Keys.Z )
  return (char)(keyValue + 32);
 return (char) keyValue;
}

if you need it to works with your current culture you should override ProcessKeyMessage Control method:

protected override bool ProcessKeyMessage( ref Message m )
{
 if ( ( m.Msg == 0x102 ) || ( m.Msg == 0x106 ) ) // this is special - don't remove
 {
  char c = (char) m.WParam; // here is your char for OnKeyDown event ;)
 }
 return base.ProcessKeyMessage( ref m );
}

Hope it helpful.

回答2:

I think that what you are looking for is in fact the KeyCode property.

private void textBox1_KeyDown(object sender, System.Windows.Forms.KeyEventArgs e)
{
    // Determine whether the key entered is the F1 key. If it is, display Help.
    if(e.KeyCode == Keys.A)
    {
        // Do something kewl
    }
    else if(e.KeyCode == Keys.B)
    {
        // Do something even kewler
    }
}

If you are just looking for certain keys you could setup a switch statment or whatever your heart desires.

回答3:

If the reason you're wanting to use KeyDown instead of KeyPress is to capture the extra information that's given to a KeyDown event, could you perhaps capture that extra information in a KeyDown event and then use it when you get the KeyPress? Rather a hokey approach, to be sure, but I'm not sure of any other approach that will really work in a keyboard mapping that has "dead keys" (i.e. two-key sequences that produce a single character). I don't know why Microsoft didn't carry along more information through to the KeyPress event (or a lot of its events, for that matter) since trying to match up cause-and-effect events isn't perfect, but I don't really know any better alternative.