how to route a message to the control's standard WNDPROC

Question

When a standard window control (eg an "EDIT" control) is created, its WNDPROC is defined as part of the window class (ie "EDIT" has a specific WNDPROC that is designed to make the window display & behave as an edit-control).

MFC allows you to interact with such controls via their wrapper classes, such as a CEdit wrappers the specialized messages for an "EDIT" window control.

MFC further allows you to bind an instance of an "EDIT" window to a C++ subclass of CEdit, say a CMyEdit , where you can override inherited virtual functions of CEdit and CWnd , and you can define a message table to gain access / override messages sent to the window instance itself.

There is CWnd::Default() , which calls this->DefWndProc with the current message arguments. This appears to lookup the WNDPROC for the HWND it is associated with. So is this the correct answer: call DefWndProc() (or equally, Default()), which will hand it off to the WNDPROC of the windows control?

Obviously, this is different than other message table handlers which can return FALSE to indicate that they didn't handle the message, and MFC will automatically route the message up the class inheritance hierarchy to the next message handler for this message, or, I assume, to Default() to be handled by the native WNDPROC ?

If I define an arbitrary message handler, say for WM_SETTEXT, what is the correct way to pass this message on to the "EDIT" WNDPROC ?

I'd also love to know if there is a way to pass the message up to a superclass (C++ class hierarchy) for handling? Many OnXXX style handlers do have a way to do so, but is there a mechanism that works for ON_MESSAGE handlers?

class CDynamicMenuControlEdit : public CEdit  
{
    ...
    LRESULT OnSetText(WPARAM wParam, LPARAM lParam);
    ...
}

BEGIN_MESSAGE_MAP(CDynamicMenuControlEdit, CEdit)
    ...
    ON_MESSAGE(WM_SETTEXT, OnSetText)
    ...
END_MESSAGE_MAP()

LRESULT CDynamicMenuControlEdit::OnSetText(
    WPARAM wParam,          // not used; must be zero
    LPARAM lParam           // window-text string (LPCTSTR)
)
{
    if (m_bHasFocus)
    {
        // do normal thing 
        // !!! THIS IS MY QUESTION: IS THIS CALLING EDIT's WNDPROC, or ::DefWinProc()? !!!
        return DefWindowProc(WM_SETTEXT, wParam, lParam);
    }
    ...
}

Clarification

You can have multiple MFC subclasses at the C++ level -

so C inherits B inherits A, where A is an MFC class (eg CEdit ).

Each of those can have an MFC message table - ie BEGIN_MESSAGE_MAP ... END_MESSAGE_MAP which can each have a handler for any arbitrary windows message, such as WM_MESSAGE(WM_SETTEXT, OnSetText) - and that OnSetText member is not necessarily virtual - just a static member (each MFC subclass can route that message in any arbitrary way).

My question is - since a WM_MESSAGE dispatch entry doesn't have a return value, how do I allow MFC to walk up the MFC dispatch tables from C to B to A before handing back to the real windows 'EDIT' class's wndproc?

Or are all such entries intended at the MFC design-level NOT to be walked? ie the most subclassed layer's dispatcher is intended to be the only one called? And if it wants to leverage an inherited member it has to manually make that call - MFC simply doesn't have any specific generic structure for this?

Answer 1

Calling Default() will cause the "normal" processing that would have happened in response to a message to occur. I'm not entirely clear on what you are trying to achieve, but it seems to me that calling Default() is what you want to do.

If you look at a lot of the handlers from Windows messages in the CWnd handlers (and handlers from classes derived from CWnd such as CEdit ) you will see that they call Default() .

Word to the wise, that Default() will actually use whatever parameters the original message had - you cannot change them.

Answer 2

You're doing it right. CWnd::DefWindowProc() uses the WINDOWPROC you subclassed from and will call the EDIT window's window procedure.