Printable View
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
Doesn't the EventArgs of the keyPress event handler give the answer like
? And why should the event handling not happen in a Form? Which szenario needs a key event handling without visualization ??Code:private void Form1_KeyDown(object sender, KeyEventArgs e)
{
if (e.Alt && e.KeyCode.ToString() == "F")
{
....
}
}
use the ModifierKeys property:
Code: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 );
}
@Both: The code is valid (:thumb:), 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.
Again, perfectly valid, but potentially confusing to the OP.Quote:
Originally Posted by MadHatter
Why use strings? IMO, it is a bad practice. Why not e.KeyCode == Keys.F?Quote:
Originally Posted by ozzy66
Also, considering the OP's skill, a few redundant, but clarifying '()' couldn't hurt. (I was somewhat confused :confused: with the code at first - took me a while to figure out operator precedence. )
Anyway, this example is straight form the MSDN docs:
With respect,Code:// If the 'Alt' and 'E' keys are pressed,
// allow the user to edit the TreeNode label.
if(e.Alt && e.KeyCode == Keys.E)
{
// ...
}
Me :)
who says they're new? My suggestion was simpler than what I wanted to suggest which was to p/invoke GetKeyState ;)
I only meant the OP. But, you are right, that statement might have been a bit rushed.Quote:
Originally Posted by MadHatter
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?Quote:
Originally Posted by MadHatter
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.)
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.Quote:
Originally Posted by TheGreatCthulhu
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.Quote:
Originally Posted by TheGreatCthulhu
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.
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...)Quote:
Originally Posted by MadHatter
Aah... :D I can definitively understand the impulse - although it's not my default approach.Quote:
Originally Posted by MadHatter
(Hmm... I'll throw him in a pool with a shark, and yell: "Fight!". That'll teach him to fish all right!)
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...)Quote:
Originally Posted by MadHatter