Take the 2-minute tour ×

I'm creating a simple framework over Win32, and I can't seem to catch any WM_COMMAND messages. I printed all the messages going through my WndProc to the output console, and there are no WM_COMMAND messages. My program consists of a window and an editbox (with the "EDIT" class).

Here is my makeshift message loop (it's just for testing):

MSG msg;
BOOL ret;
while( ( ret = ::GetMessage( &msg, NULL, 0, 0 ) ) > 0 )
    if(msg.hwnd == NULL)
    else if(ret == -1)
    else {
        ::TranslateMessage( &msg );
        ::DispatchMessage( &msg );

Here is the WndProc:

LRESULT CALLBACK Win32Base::GlobalWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
    Win32Base *pWindow;

    pWindow = reinterpret_cast<Win32Base*>( GetWindowLong( hWnd, GWL_USERDATA ) );
    if( pWindow ) {
        MSG msgdata;
        msgdata.hwnd = hWnd;
        msgdata.message = msg;
        msgdata.wParam = wParam;
        msgdata.lParam = lParam;

        return pWindow->OnMessage( msgdata );

    return DefWindowProc(hWnd, msg, wParam, lParam);

I am also subclassing the editbox. I can catch it's WM_CHAR messages and such, but there are no WM_COMMAND messages (however, they shouldn't be there I don't think).

I feel like the problem could be perhaps in the way I am handling parenting. I've added dynamic changing of a windows parent, and when a control is created, there is a chance it won't have a parent yet. So if I create a control with the WS_CHILD, it will cause an error because there is no parent. So, when I assign the parent, I also append the WS_CHILD style (or remove it, if I am removing the parent). Is this a good practice? Maybe it could be preventing the main window from receiving the editbox's WM_COMMAND messages?

Also, the editbox doesn't repaint itself when I type, I have to force it to repaint, which is very slow...

share|improve this question
If the editbox doesn't repaint itself when you type, then there is something extremely wrong with your code... Are you forwarding messages you don't handle on OnMessage? –  K-ballo Jan 5 '13 at 21:27
Unrelated, but you need to use GetWindowLongPtr and SetWindowLongPtr (note the Ptr suffix) instead of Get/SetWindowLong if you want your code to work on 64-bit Windows. Otherwise, the pointer to your Win32Base object will get truncated. –  Adam Rosenfield Jan 5 '13 at 21:35
Your else if(ret == -1) will never be true. You can safely remove it. Apart from that, an EDIT control will never receive WM_COMMAND messages. WM_COMMAND messages are sent to the parent of a BUTTON control when the button is clicked, or to the owner of a MENU when a command is selected. –  IInspectable Jan 5 '13 at 21:57
When text in an edit control changes it sends an EN_CHANGE notification to its parent. Here is a complete list of Edit Control Notifications. –  IInspectable Jan 6 '13 at 13:51
One more thing, unrelated to your question: Using GWLP_USERDATA is fairly unreliable, since everyone can read and write to it. A more robust solution is to allocate additional space through cbWndExtra in the WNDCLASS structure and store the pointer there. –  IInspectable Jan 6 '13 at 18:01

1 Answer 1

The edit control caches its parent window when it is created and never updates this, so even when you re-parent an edit control it will still send notification messages to the original parent.

One solution would be to create a dummy "wrapper" window class which hosts the edit control, and forwards notification messages sent from the edit control to its parent.

share|improve this answer
Darn, I thought about doing this, but then I found the method I was using now and thought I could work around it. I'll try this out. –  smoth190 Jan 6 '13 at 4:24

Your Answer


