Jump to content
  • Advertisement
Sign in to follow this  
Fireborn

Design issue with object oriented windowing code

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

Hey all. I'm starting up a new project and was planning to just use the nehe window creation code to get started. I felt the urge to make something a little more object oriented. I came up with the following design: *I made a class WindowsOpenGlApplication. *This class will have all the basic code to open up a single opengl window. *The class will have virtual draw, initialize, resize, etc. functions. *When I want to create an actual project, all I should have to do is define a class that inherits from WindowsOpenGlApplication and create my own versions of the draw/resize/init functions. The problem is, to generate my window, I need to pass a WndProc callback function to the RegisterClass() function. This means that the WndProc function needs to be static in my WindowsOpenGlApplication. The WndProc handles resize messages from the system, so it needs to call my virtual resize function, but it can't because it is static. Some of the guys in the chat mentioned that I could somehow pass a this pointer into my window in the CreateWindowEx() function. Then my WndProc could extract that extra data from the window and call the virtual resize function using the this pointer. I was wondering if anyone had any other ideas or critiques of my design. The idea is to be intuitive and keep things as simple as possible. Thanks guys ;D

Share this post


Link to post
Share on other sites
Advertisement
I wouldn't tie the window to OpenGL, as it prevents you from reusing your "reusable window" in contexts that don't need OpenGL.

As for the actual windowing abstraction, it's fairly simple: CreateWindow or CreateWindowEx provide a void pointer you can pass arbitrary data to. Your Window class wrapper, when it calls either of these functions, should pass "this."

Your window procedure should be a private, static method of the Window class. You can provide a pointer to this method to the Win32 API, as it will meet the signature requirements.

The WM_CREATE message will come in to your window procedure. You will have available the HWND of the window, and the pointer you passed (the LPARAM of the WM_CREATE message is a pointer to a CREATESTRUCT, which contains the pointer you passed in one of the fields).

At this point, you can either store the mapping between the HWND and the Window* in a static std::map, or store the pointer into the GWLP_USERDATA section of the window's extra storage segment. I tend to prefer the map, as it's a bit more straightforward.

All other messages are handled by first taking the HWND for the message and looking it up in the map. If you do not find a result, you do not know about the window and you do not perform processing of the message. If you do find a result, you also have the Window* that maps to that HWND. You then delegate the processing of the message to a regular method of the appropriate Window pointer.

If you want to go the "subclass" route, that delegation method can be virtual. Personally, I prefer to simply expose event hooks in the Window class and not bother subclassing it, but that's up to you.

Share this post


Link to post
Share on other sites
I have another question about this method:

Quote:

If you do find a result, you also have the Window* that maps to that HWND. You then delegate the processing of the message to a regular method of the appropriate Window pointer.


So the draw/resize/whatever virtual functions would have to be public so that I could call them with a this pointer for my window, correct?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!