MsgProc kill-window events

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

Recommended Posts

I'm sorry in advance if I wasn't supposed to ask Windows-specific code in this forum, but here goes: Since I've started my first serious Windows programming, I've never felt truly comfortable with my Windows code. I wish that there was a simple, "right" way to create a window and run a main loop, but there obviously isn't. I'm sure that every single create-your-first window tutorial I have ever looked at has been slightly different. Because of all this uncertainty, I wanted to ask the people here (who apparently know a bit more than I do) a question about creating a MsgProc(). The one I currently use (with all the game logic taken out) is shown here:
LRESULT WINAPI WinProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{

case WM_CLOSE:
DestroyWindow(hWnd);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_KEYUP:
if(wParam==VK_ESCAPE)
{
PostQuitMessage(0);
}
return 0;

}

return DefWindowProc(hWnd, msg, wParam, lParam);
}


and here is my WinMain():
INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, INT)
{
WNDCLASS wc;
wc.cbClsExtra=0;
wc.cbWndExtra=0;
wc.hbrBackground=(HBRUSH)GetStockObject(BLACK_BRUSH);
wc.hInstance=hInst;
wc.lpfnWndProc=WinProc;
wc.lpszClassName="synth";
wc.style=CS_HREDRAW | CS_VREDRAW;
RegisterClass(&wc);
HWND hwnd=CreateWindow("synth", "the_synth", WS_VISIBLE | WS_OVERLAPPEDWINDOW, 100, 100,
800, 600, 0, 0, hInst, 0);

MSG msg;
ZeroMemory(&msg, sizeof(msg));
while(msg.message!=WM_QUIT)
{
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{

if(quit_game)
{
PostQuitMessage(0);
break;
}

}
}

UnregisterClass("synth", hInst);

return 0;
}


My questions are: -Is my MsgProc() redundant? Do I really need to have procedures for WM_CLOSE, WM_DESTROY, and WM_QUIT? Does MsgProc() even handle the WM_QUIT event? -Is the basic structure of my main loop correct (in the sense that it is sound and will not generate strange bugs as soon as I test it on a friend's computer)? -Is my UnregisterClass() call necessary? It's just that someone told me in another thread that I'm not supposed to make this call and that Windows handles this stuff without being told. Is that true? I'm afraid that if I delete that line then the program will cease to be sound (in the same sense as in the previous question.) Thanks a lot!

Share on other sites
Your MsgProc looks fine. It is not necessary to handle WM_QUIT and I am certain that message never makes it to the window. At minimum I always handle WM_CLOSE and WM_DESTROY (my WM_CLOSE generally just calls DestroyWindow() and WM_DESTROY does the cleanup).

UnregisterClass() is unnecessary. Classes registered by an application are automatically unregistered when that application closes. You can call it and it wont hurt anything but most people dont bother.

Share on other sites
Thanks a lot! It will save me a lot of stress to know that I won't have to think about Windows code for a while!

Share on other sites

The only point I would make is that in general I would prefere to use the superseding 'extended' windows functions and structures, they're similar to those you are using but offer more flexibility.

The ones you want to look into are:

There is no UnregisterClassEx, just UnregisterClass, and you dont have to make this call anyway as Windows automatically sorts this out for you. The only point in it is if you want to unregister the class before the end of the program but thats a rare occurance and clearly doesnt apply in your case.

Share on other sites
What exact differences are in the "Ex" functions? Will I ever notice them?

Thanks!

Share on other sites
Quote:
 Original post by synth_catWhat exact differences are in the "Ex" functions? Will I ever notice them?Thanks!

Well thats the thing.. you might not ever need to use them, personally I just do by default (it's worth pointing out that I'm not sure if there actually are any real disadvantages to not using the Ex functions). The Ex functions just add extended functionality to what you can already do, such as setting extended-window-styles, giving a small-icon for windows, etc

Take a look at the msdn docs for more info on them.

I think ultimately the decision rests on whether you need or want this extra 'flexibilty'.
They're not difficult to use however, just an extra parameter here and there.

Share on other sites
synth_cat,

The 'Ex' functions are the extended functions. Originally Win32 was written for 16-bit code, but now this has been replaced with extended versions for 32 bit applications. Essentially, use the extended functions always, unless none is supplied.

Share on other sites
I use the Ex versions. The main advantage is you can specify different icons to use for the large and small versions of your window icon. If you only specify the large one (Which will happen if you don't use the Ex versions), Windows will shrink your large icon (32x32) image to 16x16, which may cause some artifacts. Alternatively, you could display a completely different icon if you wanted.

Share on other sites
Well, thanks a lot for explaining that! I guess I will just use extended version from now own...

Share on other sites
Quite often, the non-Ex functions are macros which map to the Ex functions.

1. 1
2. 2
3. 3
frob
20
4. 4
Rutin
19
5. 5

• 32
• 13
• 10
• 11
• 9
• Forum Statistics

• Total Topics
632558
• Total Posts
3007077

×