The following describes how to make a .NET form consume special keystrokes such as TAB and accelerator keys when it is embedded in a UI Toolkit window.

Introduction

When a .NET WinForm or WPF control is embedded in a Toolkit window, the Toolkit generally handles keyboard input as you would expect. However, certain edge cases can cause confusion. Fortunately, there are ways to redirect keyboard input to meet these needs. Unlike with the ActiveX API\'s AX_WANTSKEY routine, however, that redirection isn\'t controlled by the Toolkit application itself. Instead, the .NET form or control dictates whether or not it processes a keystroke.

Normally, keystrokes that can be mapped to menu entries (also known as "accelerators") are not translated into characters for the .NET component, while all other keystrokes are sent to the component as input. TAB and SHIFT+TAB are special cases when the Toolkit window containing the .NET form is in a composite window. If the first control within the .NET component has focus when SHIFT+TAB is pressed, the Toolkit passes that out to the container—likewise when TAB is pressed on the last control in the component.

Except for the special handling of TAB and SHIFT+TAB when in a composite window, whenever a keystroke occurs within DOTNET_TKINPUT, the Toolkit calls the PreProcessMessage method of the .NET form. If that method returns true, then the Toolkit will not attempt to translate the keystroke as an accelerator, which will cause it to be dispatched to the form as a normal keystroke. This makes keys such as TAB, SHIFT+TAB and ESCAPE work as you would expect most of the time, because the standard behavior for a .NET form is to consume those keys. (See http://msdn.microsoft.com/en-us/library/system.windows.forms.control.preprocessmessage.aspx for details on the PreProcessMessage method.)

Special cases

If you have a custom control that wants to consume TAB, SHIFT+TAB, or ESCAPE, instead of letting the form use them for navigation between controls or as an accelerator, you can override the control’s ProcessCmdKey method (see http://msdn.microsoft.com/en-us/library/system.windows.forms.control.processcmdkey.aspx) and return true to indicate that the key was processed. For example, here is part of the source for a user control written in C# that handles each of those keys by setting the text of a label to indicate what key was pressed:

Another approach to overriding keystroke behavior is to override the control’s IsInputKey method (see http://msdn.microsoft.com/en-us/library/system.windows.forms.control.isinputkey.aspx). But this method is not invoked for form-level accelerators like ESCAPE.

When you don’t have access to the code for the control, you can direct keyboard input by overriding the form’s PreProcessMessage method. Even if you’re using a pre-packaged form, you can always embed that form in your own form that overrides the keyboard input handling.