Re: AfxCallWndProc and Custom Control Development
"sawer" <sawer@discussions.microsoft.com> wrote in message
news:2C2121E3-75E1-4D74-B75E-2948C82CEEC9@microsoft.com...
Hi
In Programming with Microsoft Visual C++.NET book, author shows a custom
control dll. In his code:
/////////////////////////////////////////
LRESULT CALLBACK AFX_EXPORT
RygWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
....
//////////////////////////////////////////
I downloaded The Ultimate Toolbox code, there is no call to AfxCallWndProc
For example:
///////////////////////////////////////////
BOOL COXTabViewContainer::Create(CWnd* pParentWnd, CRect
....
///////////////////////////////////////////
In MSJ for AfxCallWndProc:
"You can think of AfxWndProc as a function with a big switch statement
that
routes WM_XXX messages to your window class's OnXXX handler functions.
This
is a first-order approximation of how AfxWndProc works:
....
If AfxWndProc routes WM_XXX messages to window class's OnXXX handler
functions, why didn't Ultimate toolbox use it?
If i derive a class from any MFC wnd class(CWnd, CFrameWnd, CEdit etc...)
haven't it got all the default wndproc for messages(because i derived it
from
CWnd class)? So why do we need to call AfxWndProc?
Think about it. When would you need to call a function that handles all
possible Windows messages sent to the window? Certainly not from the second
case (virtual Create() function); you never directly call the WndProc from
there! That's because you're focused only on window creation (the WM_CREATE
message).
In the first case, you are exporting a Window Proc to be called apparently
by another .dll or .exe module, and apparently the way it is implemented is
to turn around and let MFC handle it. For this you really do need to call a
function that handles all possible Windows messages. And that is why it
calls AfxCallWndProc.
-- David