WM_QUIT problem
Author
I am creating a window for opengl, the window appears and disapears. I have checked what PeekMessage is getting, and it appears the first and only message is WM_QUIT. So the program ends. All it should be doing is creating the opengl window and staying there.
Somewhere in your code that you don't want to show us, you're posting a WM_QUIT message.
How are you checking? If you are using a switch statement, are you using the break keyword to avoid falling through?
Are you sure you aren't doing something like: if (msg = WM_QUIT), with a single equals instead of double equals?
Author
The comparison is correct, and I am not posting any messages at all. No switch/case, its an if statement.
Message loop looks like this:
Message loop looks like this:
MSG msg;
while(1){
if(PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
if (msg.message == WM_QUIT){
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}else{
}
}
Can you also post you winproc function?
- Kevin
Agreed. The only reason for this I can think of is that you've forgotten to add a "break" after each "case" in your wndproc, and it's falling through to WM_DESTROY as soon as you get any message.
Author
LRESULT CALLBACK GLContext::wProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lpr){
switch(msg){
case WM_CLOSE:
DestroyWindow(hwnd);
break;
case WM_CREATE:
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd,msg,wparam,lpr);
}
return DefWindowProc(hwnd,msg,wparam,lpr);
}
As the documentation states: with most messages, you have to return zero if you've dealt with them. You are always returning DefWindowProc, which is not what you want.
BTW this shows how crap most tutorials are. Most people who are new to win32 has no idea what that swicth/default/return mess is doing and the tutorials fail to explain that.
The swicth with early returns or switch with breaks totally mixed, because some tutorials use the early-return zeros with return defproc after the switch, some use breaks with a default:return defproc, and a return zero after the switch.
This is a mess and the newbie has no idea what that code does, because that very simple principle is not mentioned: look it up in the message's documentation what it needs to return when handled (zero with most messages), and if you don't want to deal with a message (even "swallowing" a message means dealing with it), return [font="Courier New"]DefWindowProc[/font].
I personally prefer
Because there are some messages when you have to return something else than zero, so this structure (IMHO) is more consistent.
(sorry for the rant)
BTW this shows how crap most tutorials are. Most people who are new to win32 has no idea what that swicth/default/return mess is doing and the tutorials fail to explain that.
The swicth with early returns or switch with breaks totally mixed, because some tutorials use the early-return zeros with return defproc after the switch, some use breaks with a default:return defproc, and a return zero after the switch.
This is a mess and the newbie has no idea what that code does, because that very simple principle is not mentioned: look it up in the message's documentation what it needs to return when handled (zero with most messages), and if you don't want to deal with a message (even "swallowing" a message means dealing with it), return [font="Courier New"]DefWindowProc[/font].
I personally prefer
switch(msg)
{
case WM_WHATEVER:
DoWhatever();
return 0;
...
}
return DefWindowProc();Because there are some messages when you have to return something else than zero, so this structure (IMHO) is more consistent.
(sorry for the rant)
You should return 0 over DefWindowProc when you process everything and do not require the os to do anymore - ie you suppress further action. Having said this, that code shouldn’t cause your program to behave in the way your saying.
The fact that your window appears and then disappears suggests that you ARE processing more than just the WM_QUIT message. The code you have posted is not the cause of your problem.
Have you checked your create window function? Any chance you can post more code up?
- Kevin.
The fact that your window appears and then disappears suggests that you ARE processing more than just the WM_QUIT message. The code you have posted is not the cause of your problem.
Have you checked your create window function? Any chance you can post more code up?
- Kevin.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
