Preventing edit control text from being autoselected in a dialog box

Date:November 14, 2003 / year-entry #130
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031114-00/?p=41823
Comments:    2
Summary:By default, when the user TABs to an edit control in a dialog box, the entire contents of the edit control are autoselected. This occurs because the edit control responds with the DLGC_HASSETSEL flag in response to the WM_GETDLGCODE message. To prevent it from happening, remove that flag. LRESULT CALLBACK RemoveHasSetSelSubclassProc (HWND hwnd, UINT uiMsg,...

By default, when the user TABs to an edit control in a dialog box, the entire contents of the edit control are autoselected. This occurs because the edit control responds with the DLGC_HASSETSEL flag in response to the WM_GETDLGCODE message. To prevent it from happening, remove that flag.

LRESULT CALLBACK RemoveHasSetSelSubclassProc
    (HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam,
     UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
    switch (uiMsg) {
    case WM_NCDESTROY:
        RemoveWindowSubclass(hwnd, RemoveHasSetSelSubclassProc,
                             uIdSubclass);
        break;
    case WM_GETDLGCODE:
        return DefSubclassProc(hwnd, uiMsg, wParam, lParam)
                             & ~DLGC_HASSETSEL;
    }
    return DefSubclassProc(hwnd, uiMsg, wParam, lParam);
}

All this subclass procedure does is remove the DLGC_HASSETSEL flag from the return value of the WM_GETDLGCODE message.

INT_PTR CALLBACK DlgProc(HWND hdlg, UINT uiMsg,
                         WPARAM wParam, LPARAM lParam)
{
    switch (uiMsg) {
    case WM_INITDIALOG:
        SetWindowSubclass(GetDlgItem(hdlg, 100),
                          RemoveHasSetSelSubclassProc, 0, 0);
        break;
    case WM_COMMAND:
        switch (GET_WM_COMMAND_ID(wParam, lParam)) {
        case IDCANCEL:
            EndDialog(hdlg, 1);
            break;
        }
    }
    return FALSE;
}

The subclass procedure is installed when the dialog box is initialized.

int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hinstPrev,
                   LPSTR lpCmdLine, int nShowCmd)
{
    DialogBox(hinst, MAKEINTRESOURCE(1), NULL, DlgProc);
    return 0;
}

1 DIALOGEX DISCARDABLE  0, 0, 200,200
STYLE DS_SHELLFONT | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "sample"
FONT 8, "MS Shell Dlg"
BEGIN
  CONTROL         "Blah blah",100,"Edit",WS_TABSTOP,7,4,100,10
    DEFPUSHBUTTON "&Bye", IDCANCEL, 7,24,50,14, WS_TABSTOP
END

And here is the dialog box that we display.

There really isn't much to it, but I figured a complete sample program might help somebody out. Plus it lets me show off the SetWindowSubclass function.


Comments (2)
  1. Joe says:

    (I hope people understand that this is really only acceptable for multi-line edit controls, ala Notepad or this blog, or possibly read-only controls (there may be other, special case exceptions). Having the text of an edit control become selected is a consistent user-experience across Windows — when I tab to a single-line edit control I expect the text to be highlighted so that if I start typing a new value, the old value disappears. To change this behavior, even if you don’t agree with it, just confuses users.

    In my opinion, of course.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index