tag:blogger.com,1999:blog-8166852.post3670808941036697609..comments2009-06-10T12:34:25.678-06:00Yakko Warnerhttps://profiles.google.com/102705077104052556673noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-8166852.post-43221970821076757602009-06-10T12:34:25.678-06:002009-06-10T12:34:25.678-06:00Addendum: Apparently, you should also be aware that, in a KeyDown event, setting the Handled property of the event args doesn&#39;t actually suppress the key; you also want to set the SuppressKeyPress flag.<br /><br />If you want a low-level explanation, <a href="http://blogs.msdn.com/jfoscoding/archive/2006/01/30/519406.aspx" rel="nofollow">this blog post</a> (and the comments therein) seem to suggest it has to do with a difference in the way Windows Forms queues and/or handles window messages.<br /><br />The high-level view, though: if you don&#39;t SuppressKeyPress, you may end up wondering why the heck your TextBoxes beep at you when you tab out of them. Then you might, say, turn your text box into a multi-line to see what happens, notice it&#39;s getting a tab character inserted into its text area, and wonder why Handled isn&#39;t handling it; which, if you&#39;re lucky, will eventually have to stumbling upon the SuppressKeyPress property, which might send you googling for an answer as to why there&#39;s a second property that does what the first one is supposed to, but doesn&#39;t. (Note the sample code in the <a href="http://msdn.microsoft.com/en-us/library/system.windows.forms.keyeventargs.handled.aspx" rel="nofollow">MSDN article</a> that seems to suggest Handled aborts a key press, even though the Remarks suggest it doesn&#39;t, although for the life of me I can&#39;t figure out why it <i>shouldn&#39;t</i> besides they just made it so.)Yakko Warnerhttp://www.blogger.com/profile/12276550157896918123noreply@blogger.com