How to kill focus of “edit” control on “Enter” key press

Question

I have a main window created in main function. In procedure for the main window on WM_CREATE message I create a edit control which as a child of parent window using system "edit" window class. I want the focus to be transferred to main window when enter key is pressed in edit control. Since I used system class I don't have access to its procedure. I am using C++ for this in Visual Studio 10 Since I'm new to win32 apps I want a simple solution no matter how long the code is

Answer 1

If your window has only one focusable control (such as an edit control), then that control will always have the focus. You cannot have a window with no focused controls, and the parent window itself is not focusable (ie cannot have the focus).

So you will first need to add another focusable control to your window, if you don't have one already (I couldn't tell from the question). For example, you might add an "OK" or "Cancel" button. That way, whenever you unfocus the edit control, the button can receive the focus.

Then, you will need to subclass the edit control so that you can process its key press events (eg WM_KEYDOWN and WM_KEYUP ). To subclass a single window, call the SetWindowLongPtr function and pass the window handle along with the GWLP_WNDPROC flag and a pointer to your custom window procedure. This effectively replaces the default window procedure for that class of control with your custom window procedure. For example:

// Stores the old original window procedure for the edit control.
WNDPROC wpOldEditProc;

// The new custom window procedure for the edit control.
LRESULT CALLBACK CustomEditProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch (msg)
    {
        case WM_KEYDOWN:
        {
            if (wParam == VK_RETURN)
            {
                // The user pressed Enter, so set the focus to the other control
                // on the window (where 'hwndOther' is a handle to that window).
                SetFocus(hwndOther);

                // Indicate that we processed the message.
                return 0;
            }
        }
    }

    // Pass the messages we don't process here on to the
    // original window procedure for default handling.
    CallWindowProc(wpOldEditProc, hWnd, msg, wParam, lParam);
}

// ----- Add to the parent window's WM_CREATE: -----

// Create the edit control
HWND hwndEdit = CreateWindowEx(...);

// Subclass it.
wpOldEditProc = (WNDPROC)SetWindowLongPtr(hwndEdit,
                                          GWLP_WNDPROC,
                                          (LONG_PTR)CustomEditProc);

// Show it.
ShowWindow(hwndEdit, SW_SHOW);

// ... your other code (e.g. creating and showing the other control)

// ----- Add to the parent window's WM_DESTROY: -----

// Unsubclass the edit control.
SetWindowLongPtr(hwndEdit, GWLP_WNDPROC, (LONG_PTR)wpOldEditProc);

// ... your other code (e.g. calling PostQuitMessage(...) to close your app)

Further reading about subclassing windows is here on MSDN . The sample code there (and lots of other places on the web) assumes that you're subclassing an edit control in a dialog window. Because dialogs are special types of parent windows that handle a lot of keyboard processing automatically, you need to take extra steps to overcome this default processing done by the dialog. If you're using a regular window created with CreateWindowEx , that is not necessary.

If you want multiple edit controls that all behave the same way in response to certain key presses, it is much cleaner and better design to register a custom window subclass. Whereas the above code subclassed only a single edit control object, this approach would create a new type of custom edit control class. You could create as many instances of this new type of edit control as you wanted, and they would all behave the same way.

But I won't go into how to do that here. You can find the code online if you're interested, and your particular use case makes it a bit more complicated. In order to change the focus, the control has to know which other control it should set the focus to. This is difficult to handle globally. Using a dialog window as the parent might be advisable. It manages the Z order and setting the focus for you automatically.