Archived

This topic is now archived and is closed to further replies.

Win32 program structure

This topic is 4946 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

I was just curious about how those of you who program Win32 apps set up your program structure. Since the windows messages seem to force a huge switch statement in the callback procedure, how to you manage it? I have my own ideas, but I''m curious as to how others keep their code from being one massive switch statement. -Kirk

Share this post


Link to post
Share on other sites
There aren''t really all that messages you need to handle, so the idea of there being a "huge" switch statement is kind of off base. You don''t need to handle every message. For most apps, you probably won''t need to handle more than a half-dozen.

Share this post


Link to post
Share on other sites
True, but do you handle them within the switch statement or do you pass them off to other functions? For example, do you have an application object (or "game engine" object) on which you call functions in response to the messages?

-Kirk





[edited by - KirkD on May 30, 2004 11:34:26 AM]

Share this post


Link to post
Share on other sites
When making games limit the use of the winproc to catch if the app is losing focus etc.
The game code should not use the windows programming model.
You will want to hide it somewhere and make a call to HandlePlatformDependatStuff() once every iteration of the game loop or something, on windows that function would handle the message pump.

Ofcourse, if you are just beginning, there is nothing wrong with using the winproc and the windowsmodel to make your games.

Share this post


Link to post
Share on other sites
Peter,

Thanks for the note. As I mentioned in my last post, I was thinking to make a game object with an interface which would get called by the WinProc when the interesting messages came through.

Your post gives me another idea: make the same game object but rather than WinProc forcing things to be handled, it will adjust various settings within the object. Then, once per game loop, the game object will make the necessary adjustments based on those settings.

The old way would have the game object adjusting itself everytime a windows messages came through. The new idea would set a variety of properties and only make the adjustments once per loop. Does that make sense?

-Kirk

Share this post


Link to post
Share on other sites