Jump to content
  • Advertisement

Archived

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

Vahmpire

window procedures & OO

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

Here is my problem: I am writing a Win32API tetris clone (like everyone) and I am trying to make it Object Oriented. Basically I have one big Game object that contains everything. The WinMain function just launches the app->init() and app->run() methods. (and of course delete app) Now the problem, I want my LRESULT CALLBACK function to be part of the game object as a private method (it seems the logical way to be), but somehow I am not allowed to do that. The problem is when i try to set the lpfnWndProc member of the window class I can''t set it to a non-global procedure (or so it seems). Now my current solution is I have the message handler as a global. Of course when I handle all the messages I need access to the game''s data (which is of course embedded and I don''t want to write 1.000.000 GetX() functions). So I made the game object (app) global too and all the global message handler does is call ANOTHER message handler (which is just LRESULT, no CALLBACK) which is a method contained in the object. This works, but I think it''s a very lame way to do it. So, I would very much appreciate it if you could give me any help... I''m kinda lost now. Thanks in advance!

Share this post


Link to post
Share on other sites
Advertisement
It doesn''t work because member functions have the "this" pointer as an implicit parameter so it knows what object to operate on. When flung around as a function pointer, you have no way for the compiler to know what object is actually calling the function and thus no way for the program to know which data to operate on.

Your easiest option is to make your WindowProc a private static member of your Game object class. This will work, provided you don''t ever need to access non-static data in the Game class from the callback. If you can make that function and all the data it accesses static without compromising your program, I recommend doing that.

A more robust (though more confusing solution) is to make just the callback static and add a pointer to an instance of the Game class in the class. Then handle the WM_NCCREATE message by using SetWindowLong() to pass in a pointer to the correct instance of the Game class. Retrieve it when a message comes in and use that pointer to call the member function for the actual window instance you want. I know, that sounds confusing... Oluseyi (I think) wrote an article on how to do it that explains it better. The article is somewhere on this site... Here it is!.

Look it over. It should help you some.

-Auron

Share this post


Link to post
Share on other sites

  • 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!