The following code fragment shows the structure of a typical window procedure and how to use the message argument in a switch statement, with individual messages handled by separate case statements. Notice that each case returns a specific value for each message. For messages that it does not handle itself, the window procedure calls WinDefWindowProc.

    MRESULT ClientWndProc(
    HWND hwnd,
    ULONG msg,
    MPARAM mp1,
    MPARAM mp2)
    {
        /* Define local variables here, if required. */
        switch (msg) {
            case WM_CREATE:

        /* Initialize private window data.           */
            return (MRESULT) FALSE;

            case WM_PAINT:

        /* Paint the window.                         */
            return 0;

            case WM_DESTROY:

        /* Clean up private window data.             */
            return 0;

            default:
            break;
         }
         return WinDefWindowProc (hwnd, msg, mp1, mp2);
    }

A dialog window procedure does not receive the WM_CREATE message; however, it does receive a WM_INITDLG message when all of its control windows have been created. At the very least, a window procedure should handle the WM_PAINT message to draw itself. Typically, it should handle mouse and keyboard messages as well. Consult the descriptions of individual messages to determine whether your window procedure should handle them.

An application can call WinDefWindowProc as part of the processing of a message. In such a case, the application can modify the message parameters before passing the message to WinDefWindowProc or can continue with the default processing after performing its own operations.