Advertisement Jump to content


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


window procedures & OO

This topic is 5354 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
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.


Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!