I was just wondering, how do you guys structure your win32 code? In the callback function for the main window, do you handle all the window messages in the callback function or do you write individual functions to handle each message (i.e. MainWndProc_OnKeyDown(bla bla bla) to handle WM_KEYDOWN)? I got a rather big headache because my switch statement ran into something like 2,000 lines. So I packed up all my code into functions and tried to make things neater and more readable.

  
//instead of doing this

switch(uMsg)
{
case WM_KEYDOWN:
//do your stuff here

}

//I now do this

switch(uMsg)
{
case WM_KEYDOWN:
MainWndProc_OnKeyDown(hWnd, wParam, lParam);//my own function

}

  

Is this a good idea? Or shall I try some other style? Thanx

I think if you are going to have lots of messages, its good to make functions, cuz it is nicer and more readable. For example, when initializes objects and creating surfaces in a directx application, you could right the whole thing on a WM_CREATE message, but it is probably good to put everything in a function called InitDX for example.

thanks, SaiSoft

I think if you are going to have lots of messages, its good to make functions, cuz it is nicer and more readable. For example, when initializes objects and creating surfaces in a directx application, you could right the whole thing on a WM_CREATE message, but it is probably good to put everything in a function called InitDX for example.

thanks, SaiSoft

You''re on the right track. Here''s what I did:

I created a WinApp class that has empty virtual functions for the most common messages I use in most/all of my games (OnCreate, OnDestroy, etc). All my winmain and message processing function does is call the appropriate functions in the WinApp class for those messages. This way all I have to do to use a particualr message is derive a new class from that class and implement the game specific functions I want to use.

All other non-processed messages gets thrown to my WinApp ProcessMessage function which gives the derived class a chance to call their own defined function for all other messages.

Not only does this hide almost all window specific functionality, but makes for some very solid code-reuse.

Of course it looks like you are programming in C and not C++, but you can do the same thing in C with a little more effort.


- Houdini

You can check for a message within a range and then call a function that checks for a specific messages in that range. Better though would be to call several functions that each handle a subset of messages, i.e. all mouse messages. You have those functions return a value indicating whether it handled the message or not. You call down the list until one of them says they handled it. You should put the most common messages toward the start of the list, i.e. mouse messages first. I generally wouldn''t call more than ten functions from an individual function so I would most likely use multiple levels of functions. Grouping logically related functions is certainly more important than grouping a precise number of functions so 10 certainly is no absolute number.

Take a peek at windowsx.h. This not very well documented header lets you do the "one proc per message" style very neatly and breaks down all the wParam/lParam garbage for you so you don''t have to remember it. The result looks something like:

WindowProc(...){    switch (message)    {        HANDLE_MSG(hWnd, WM_COMMAND, OnCommand);        /* other HANDLE_MSG''s */    }}void OnCommand(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify) {/*...*/} 

-Mike