When to use DefWindowProc

[sinsi]

I know that any messages you don't process should be passed on to DefWindowProc, and sometimes you call DefWindowProc and adjust the return values.
The SDK says (e.g. WM_CREATE) that you should return 0 if you process the message.
I was wondering if calling DefWindowProc at the start of WM_CREATE will do any 'default' processing? Similar to Delphi's 'inherited'.

[jj2007]

Interesting question. You might find out by returning 0...

I occasionally use DefWindowProc before doing my stuff:

Code Select Expand

CASE WM_NCPAINT
invoke DefWindowProc, hWin, uMsg, wParam, lParam
call DispMenu
or eax, -1
ret


This is needed because I paint the RichMasm menus on the non-client area after Windows draws it.

Anyway, I am curious what the gurus have to say on that issue ::)

[Relvinian]

This comes from my Visual Studio development platform about DefWindowProc:

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

So, it is really up to you to decide if you want to call it if you are processing a message or not.  If you don't need the default stuff windows does behind the scenes or change the params before calling it, then probably shouldn't call it.

The return value is the most important part when processing your own messages.  Like if you process WM_NCCREATE and return a FALSE, you are telling windows to fail the creation of the window and WM_CREATE won't ever be called, etc.

Relvinian

[sinsi]

Is there any way of telling what the default does though? A few let you know - WM_CTLCOLORSTATIC ("By default, the DefWindowProc function selects the default system colors for the static control.") but most just say if you handle it return 0 (or TRUE for others  ::)) and some say the return value is ignored.