views:

73

answers:

3

Hi

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.

A: 

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.

Adkins
+1  A: 

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.

mastak
And how i considering the active language? for example, if the active language is russian, i want to get russian chars.
DxCK
You should override ProcessKeyMessage Control method like described in my post.
mastak
the second code is enough, it catches the shfit as well.
Itay
A: 

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.

supercat
The reason I want use `KeyDown` instead of `KeyPress` is to reduce the time between user pressing a key until the response of my program. `KeyPress` firing only after the user left the key, and this adds extra unnecessary time until my program responding.
DxCK