Sign in to follow this  

Why does CreateWindowW fail?

This topic is 1914 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hmmm, that did it... WTF lol...

Is it acceptable to just redefine my WndProc like so:

[source lang="cpp"]
LRESULT Window::WndProc( UInt32 msg, WPARAM wParam, LPARAM lParam ) {

HDC hDC;
PAINTSTRUCT paintStruct;

switch( msg )
{
case WM_PAINT:
hDC = BeginPaint( this->hWnd, &paintStruct );
EndPaint( this->hWnd, &paintStruct );
break;

case WM_SIZE:
this->width = (Int32)LOWORD(lParam);
this->height = (Int32)HIWORD(lParam);
break;

case WM_SETTEXT:
this->title = wstring( reinterpret_cast<WCHAR_STR>(lParam) );
break;

case WM_DESTROY:
PostQuitMessage( 0x00 );
break;
}

return DefWindowProc( this->hWnd, msg, wParam, lParam );
}
[/source]

???

Now my text is changing correctly, but I just want to be sure that structuring my WndProc method like this is ok and isn't going to cause any problems for my class. The original version was returning 0x00 instead of the result of DefWindowProc.

[b]EDIT:[/b]

I assume that if I do it this way and I want to block Windows from getting a message then I can replace a break with a return. Edited by ATC

Share this post


Link to post
Share on other sites
That's what I spoke about in my first post. Always return DefWindowProc() for all messages, even the ones you process, except in the case where you know that you do NOT want DefWindowProc() to process the message, and that the value you are returning instead is meaningful to the system. DefWindowProc() does A LOT of things, and the less you interfere with it (the less messages you keep from it), the less problems you are likely to have. So yes, that structure of the message procedure is the natural one.
[quote]I assume that if I do it this way and I want to block Windows from getting a message then I can replace a break with a return.[/quote]
Yep, but again, see the documentation for the message in question to know what to return. Edited by Amr0

Share this post


Link to post
Share on other sites
[quote name='Amr0' timestamp='1350760045' post='4992233']
That's what I spoke about in my first post. Always return DefWindowProc() for all messages, even the ones you process, except in the case where you know that you do NOT want DefWindowProc() to process the message, and that the value you are returning instead is meaningful to the system. DefWindowProc() does A LOT of things, and the less you interfere with it (the less messages you keep from it), the less problems you are likely to have. So yes, that structure of the message procedure is the natural one.
[quote]I assume that if I do it this way and I want to block Windows from getting a message then I can replace a break with a return.[/quote]
Yep, but again, see the documentation for the message in question to know what to return.
[/quote]

Gotcha! Thanks a lot! :-)

I've got a nice general purpose Window class coming together now... now working on wiring up some events and such. When it's done I won't feel so bummed out every time I start a new Win32 or native DirectX project (from having to do all this crap over again). :P

Thanks again,

--ATC--

Share this post


Link to post
Share on other sites
CRAP! I cannot believe I missed that! You don't need to process WM_CREATE or WM_PAINT or most of the other messages, but you do need to return DefWindowProc().[img]http://public.gamedev.net//public/style_emoticons/default/sleep.png[/img]

Share this post


Link to post
Share on other sites

This topic is 1914 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this