Win32 Question

Started by
17 comments, last by jflanglois 18 years, 5 months ago
Well there is at least one problem...your window proc is always calling default.

It should be like this:

switch( blah )
{
case BLAH:
// return a value...
break;

case FOO:
// return a value...
break;

default:
return DefaultWindowProc( );
}


And if you really want to be cool: A lot of people think that functions should have one entry point and one exit point. So you could do:

LRESULT blah;

switch( )
{
case FOO:
blah = something; // what I would normally have returned

default:
blah = DefaultWindowProc( );
}

return blah;
Advertisement
Quote:Original post by ProgramMax
Well there is at least one problem...your window proc is always calling default.

It should be like this:

switch( blah )
{
case BLAH:
// return a value...
break;

case FOO:
// return a value...
break;

default:
return DefaultWindowProc( );
}


And if you really want to be cool: A lot of people think that functions should have one entry point and one exit point. So you could do:

LRESULT blah;

switch( )
{
case FOO:
blah = something; // what I would normally have returned

default:
blah = DefaultWindowProc( );
}

return blah;


I can step through the code with the debugger and I can tell that is is not calling the default window proc every pass. Whats the point in a return; followed by a break;? For the hell of it, I put the default function under the default case, but that still does not help fix my problem.

www.EberKain.comThere it is, Television, Look Listen Kneel Pray.
ProgramMax is partly right.
The big problem is your WM_SYSCOMMAND case.

You can change it to:
case WM_SYSCOMMAND:	switch (*p_wparam)	{		case SC_SCREENSAVE:		case SC_MONITORPOWER:			return 0;					}	return DefWindowProc(*p_hwn, *p_msg, *p_wparam, *p_lparam);

and it should work. [edit] As an explanation, when you effectively intercept the WM_SYSCOMMAND message, you do not handle all the system commands apart from SC_SCREENSAVE and SC_MONITORPOWER, such as SC_MOVE. You need to pass those to DefWindowProc. [edit2] Improved the code slighly.


jfl.

[Edited by - jflanglois on November 4, 2005 5:15:40 PM]
Quote:Original post by jflanglois
ProgramMax is partly right.
The big problem is your WM_SYSCOMMAND case.

You can change it to:
case WM_SYSCOMMAND:	switch (*p_wparam) {		case SC_SCREENSAVE:		case SC_MONITORPOWER:			return 0;		default:			DefWindowProc(*p_hwn, *p_msg, *p_wparam, *p_lparam);	}return 0;

and it should work. [edit] As an explanation, when you effectively intercept the WM_SYSCOMMAND message, you do not handle all the system commands apart from SC_SCREENSAVE and SC_MONITORPOWER, such as SC_MOVE. You need to pass those too DefWindowProc, thusly the default: section


jfl.


Excellent, that fixed it. Thanks a ton.
www.EberKain.comThere it is, Television, Look Listen Kneel Pray.
You aren't supposed to call Defaultblah( ) every time. You only call it when you didn't handle the message yourself.

That's why I put it in the default case. Your most recent post puts it in the default case...but that is inside a specific case of a seperate switch.

You need the outter-most switch to have the default.
Oh also the reason I put the breaks there is because of the one entry / one exit idea.
Quote:Original post by ProgramMax
You aren't supposed to call Defaultblah( ) every time. You only call it when you didn't handle the message yourself.

That's why I put it in the default case. Your most recent post puts it in the default case...but that is inside a specific case of a seperate switch.

You need the outter-most switch to have the default.


Well, the structure of his message handler effectively does the same thing. He moved return 0 to the inside of the switch.

switch( msg ) {  case WM_CLOSE:    PostQuitMessage( 0 );    break;  default:    return DefWindowProc( hwnd, msg, wp, lp );}return 0;
Is functionally the same as:
switch( msg ) {  case WM_CLOSE:    PostQuitMessage( 0 );    return 0;}return DefWindowProc( hwnd, msg, wp, lp );


I tend to use breaks as well. But his way is also valid.

The reason I moved DefWindowProc outside of the WM_SYSCOMMAND case is because I am not certain whether it will perform additional work on SC_SCREENSAVE and SC_MONITORPOWER. I may be wrong there.


jfl.
Hehe whoops. Apparently my first time reading through I didn't notice any of those tons of returns.

You are right. Sorry about that.
No need to apologize. I didn't notice them at first either.


jfl.

This topic is closed to new replies.

Advertisement