Problem getting 'alt' key from user

[FatCat82]

Hi


I cannot find a way to recognize an 'Alt + key' combination from the user.

Now I cannot override ProcessCmdKey since the event handling isn't done in the Form - I can access the Control attribute but the only events I can advise on are KeyUp, KeyDown (Unless I'm missing something)

keyDown - Doesn't intercept 'Alt + whatever'
keyUp - Intercepts the event only after BOTH alt and the key are up - not good enough since I need to handle continious key pressing


Any help will be greatly appreciated

[ozzy66]

Doesn't the EventArgs of the keyPress event handler give the answer like

private void Form1_KeyDown(object sender, KeyEventArgs e)
{
  if (e.Alt && e.KeyCode.ToString() == "F")
  {
    ....
  }
}

? And why should the event handling not happen in a Form? Which szenario needs a key event handling without visualization ??

[MadHatter]

use the ModifierKeys property:

private void HandleKeyDownEvent( object sender, KeyEventArgs e ) {
    string message = string.Format( "key {0} pressed, Alt pressed? {1}", e.KeyCode, ( ( ModifierKeys & Keys.Alt ) == Keys.Alt ) ? "yes" : "no" );
    MessageBox.Show( message );
}

[TheGreatCthulhu]

@Both: The code is valid (), but don't you think that someone relatively new to this should be presented with something more straightforward and clear?
If the OP doesn't understand event handling, maybe an extra explanation is needed.

string message = string.Format( "key {0} pressed, Alt pressed? {1}", e.KeyCode, ( ( ModifierKeys & Keys.Alt ) == Keys.Alt ) ? "yes" : "no" );

Again, perfectly valid, but potentially confusing to the OP.

private void Form1_KeyDown(object sender, KeyEventArgs e)
{
  if (e.Alt && e.KeyCode.ToString() == "F")
  {
    ....
  }
}

Why use strings? IMO, it is a bad practice. Why not e.KeyCode == Keys.F?
Also, considering the OP's skill, a few redundant, but clarifying '()' couldn't hurt. (I was somewhat confused with the code at first - took me a while to figure out operator precedence. )

Anyway, this example is straight form the MSDN docs:

   // If the 'Alt' and 'E' keys are pressed,
   // allow the user to edit the TreeNode label. 
   if(e.Alt && e.KeyCode == Keys.E)
   {
        // ...
   }

With respect,
Me

[MadHatter]

who says they're new? My suggestion was simpler than what I wanted to suggest which was to p/invoke GetKeyState

[TheGreatCthulhu]

who says they're new?

I only meant the OP. But, you are right, that statement might have been a bit rushed.

who says they're new? My suggestion was simpler than what I wanted to suggest which was to p/invoke GetKeyState

Now, generally speaking, why would you do that in C# (that is, if the requirements don't imply any specific/significant benefit form it)? And you were just willing to assume that the OP is familiar with the Windows API?

Again, I admit that I could be mistaken and that FatCat82 will have no trouble with the code, maybe I misjudged his/hers knowledge level.
Don't get me wrong, I didn't mean to imply anything - I was just saying.

Also, I'd like to add that the KeyData property of the KeyEventArgs class can also be used, which encodes modifier keys into the bit-pattern of the result.
(But the preferred way is to use the corresponding properties.)

[MadHatter]

I only meant the OP. But, you are right, that statement might have been a bit rushed.

I read it as they were rushed. I hoped they were rushed, and didn't suggest what I wanted to because I had hoped this was the scenario.

Now, generally speaking, why would you do that in C#? And you were just willing to assume that the OP is familiar with the Windows API?

Pure sadism for folks unable to type "c# keypress alt" into google and click through the first 10 links for an answer. GetKeyState (in C++) is actually pretty useful generally speaking. Unfortunately the .net folks didn't entirely wrap that api up in the framework. They did however implement it (oddly enough) inside the Control.ModifierKeys property for control / shift / alt--which--not surprisingly the very event args we're talking about use to obtain its shift/control/alt key state info.

not that it applies here, but one of my pet peeves in the world of .net is the attitude of "well, the .net team didn't provide X and Y so we should either work with what's here, or write some really bloated managed implementation, because p/invoking, and native code is far worse."

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

need to make sure we're not just handing out fish sometimes.

[TheGreatCthulhu]

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

I absolutely agree with that - cargo-cult student programmers that try their luck here must find me so annoying... (And I've been known to give them a rough time if they happen to go too far...)

Pure sadism for folks unable to type "c# keypress alt" into google and click through the first 10 links for an answer. [...]
need to make sure we're not just handing out fish sometimes.

Aah... I can definitively understand the impulse - although it's not my default approach.
(Hmm... I'll throw him in a pool with a shark, and yell: "Fight!". That'll teach him to fish all right!)

not that it applies here, but one of my pet peeves in the world of .net is the attitude of "well, the .net team didn't provide X and Y so we should either work with what's here, or write some really bloated managed implementation, because p/invoking, and native code is far worse."

Yeah, there's that too. Such attitudes probably come from people who lack proper understanding of the topic. In relation to that, and keeping in mind that one of he conceptual goals of .NET is portability, the system can be always designed so that the platform-specific code stays isolated - IMO it's a good practice to do so in any case. (I don't know how mature are other, non-Microsoft CLR implementations such is Mono, though...)