Quote:Original post by RealMarkP
So, if I create a dummy global function that just returns a DefWindowProc() call, it would catch the WM_CREATE, etc messages. I'm not too worried about not catching WM_CREATE messages.
You could, but you can't do any message processing in your main message loop.
For instance, WM_SIZING is sent to your window when it's being resized. Calling DefWindowProc says "Ok, I'm happy with that size", and you can change the size before calling it. It's not valid to modify the sizing rect outside of the window proc.
Also, there are functions like TranslateMessage which emit messages to your window proc - without a window proc you'll never get WM_CHAR messages and probably a bunch more.
You may not be "too worried about not catching WM_CREATE messages" just now, but if you ever need to create child windows (Such as buttons or toolbars), you'll need to - and it's not possible without a window proc.
This topic has come up a fee times, and every time the answer is "Don't do it". Even if it happens to work just now, it's the sort of thing that'll just break horribly on other PCs, if there's any software on the PC that hooks any window messages, if it's a different windows version, different service pack, or different anything, or if you try to handle a new message type. It's really not worth the hassle.
Why do you want to do away with your window proc? If it's for encapsulation, it's normal to wrap your window proc up in a class to make it all nice and OOPy...