Some CTRL Accelerator Keys Conflict with Edit Controls

• Microsoft Windows Software Development Kit (SDK) versions 3.0 and 3.1
• Microsoft Win32 Application Programming Interface (API) included with:

      - Microsoft Windows NT versions 3.5 and 3.51
      - Microsoft Windows 95 version 4.0
  

SUMMARY

Some keys produce the same ASCII values as CTRL+key combinations. These keys conflict with edit controls if one of the CTRL+key combinations is used as a keyboard accelerator.

The following table lists some of the conflicting keys.

   ASCII Value  Key Combination  Equivalent  Windows Virtual Key
   -----------  ---------------  ----------  -------------------
   0x08         CTRL+H           BACKSPACE   VK_BACK
   0x09         CTRL+I           TAB         VK_TAB
   0x0D         CTRL+M           RETURN      VK_RETURN

1. CTRL+H has been assigned as an accelerator keystroke to invoke Help

2. An edit control has the focus

3. BACKSPACE is pressed to erase the previous character in the edit control

MORE INFORMATION

When messages for the edit control are processed in a message loop that translates accelerators, this translation conflict will occur. Child windows and modeless dialog boxes are the most common situations where this happens.

The affected keystrokes are translated during the processing of the WM_KEYDOWN message for the letter. For example, when the user types CTRL+H, a WM_KEYDOWN is processed for the CTRL key, then another WM_KEYDOWN is processed for the letter "H". In response to this message, TranslateAccelerator() posts a WM_COMMAND message to the owner of the CTRL+H accelerator. Similarly, when the user presses the BACKSPACE key, a WM_KEYDOWN is generated with VK_BACK as the key code. Because the ASCII value of BACKSPACE is the same as that for CTRL+H, TranslateAccelerator() treats them as the same character. Either sequence will cause a WM_COMMAND message to be sent to the owner of the CTRL+H accelerator, which deprives the child window with the input focus of the BACKSPACE key message.

Because this conflict is inherent to ASCII, the safest way to avoid the difficulty is to avoid using the conflicting sequences as accelerators. Any other ways around the problem may be version dependent rather than a permanent fix.

A second way around the situation is to subclass each edit control that is affected. In the subclass procedure, watch for the desired key sequence(s). The following code sample demonstrates this procedure:

/* This code subclasses a child window edit control to allow it to
 * process the RETURN and BACKSPACE keys without interfering with the
 * parent window's reception of WM_COMMAND messages for its CTRL+H
 * and CTRL+M accelerator keys.
 */

/* forward declaration */

/* required global variables */

HWND    hWndOwner;


/* edit control creation in MainWndProc */

...

 case WM_CREATE:

    hDC = GetDC(hWnd);
    GetTextMetrics(hDC, &tm);
    ReleaseDC(hWnd, hDC);

    hWndEdit = CreateWindow("Edit", NULL,
        WS_CHILD | WS_VISIBLE | ES_LEFT | WS_BORDER,
        50, 50, 50 * tm.tmAveCharWidth, 1.5 * tm.tmHeight,
        hWnd, 1, hInst, NULL);

    lpfnOldEditProc = (FARPROC) GetWindowLong (hWndEdit, GWL_WNDPROC);
    lpProcEdit = MakeProcInstance ((FARPROC) NewEditProc, hInst);
    SetWindowLong(hWndEdit, GWL_WNDPROC, (LONG) lpProcEdit);
    break;

/* subclass procedure */

                            WORD wParam, LONG lParam )
{
  MSG  msg;

  switch (iMessage)
    {
  case WM_KEYDOWN:
    switch (wParam)
        {
    case VK_BACK:
        // This assumes that the next message in the queue will be a
        // WM_COMMAND for the window which owns the accelerators. If
        // this edit control were in a modeless dialog box, hWndOwner
        // should be set to NULL. It may also be NULL in this case.
        PeekMessage(&msg, hWndOwner, 0, 0, PM_REMOVE);

        // Since TranslateAccelerator() processed this message as an
        // accelerator, a WM_CHAR message must be supplied manually to
        // the edit control.
        SendMessage(hWndEditCtrl, WM_CHAR, wParam, MAKELONG(1, 14));
        return 0L;

    case VK_RETURN:
        // Same procedures here.
        PeekMessage(&msg, hWndOwner, 0, 0, PM_REMOVE);
        SendMessage(hWndEditCtrl, WM_CHAR, wParam, MAKELONG(1, 28));
        return 0L;
        }
        break;
    }
    return CallWindowProc(lpfnOldEditProc, hWndEditCtrl, iMessage,
                          wParam, lParam);
}