Jump to content
  • Advertisement
Sign in to follow this  
Grofit

Window Message Pump... within a class...??

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

Hello, Im trying to make a class for managing creating windows, which will then derive to create OpenGL/Direct3D windows.... anyway to create a window i need a pointer to the window message pump (i.e):
LRESULT CALLBACK cBaseWindow::Window_Message_Pump(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
..
}
}
As you can see above the message pump is part of my cBaseWindow class, and i dont seem to be able to get a valid function pointer to create a window... am i able to put the message pump within its own class? i would presume i can, im just doing it wrong... Can anyone point me in the right direction? ive tried the basic techniques:
// Both with address operator and with/without the scope prefix
&cBaseWindow::Window_Message_Pump;
&Window_Message_Pump;

// Same as above but without address operator
cBaseWindow::Window_Message_Pump;
Window_Message_Pump;
ive also tried creating a member function pointer but it just refuses to point to it, im not sure if the CALLBACK aspect screws it up... any help would be great.. Thanks, Grofit

Share this post


Link to post
Share on other sites
Advertisement
Thanks for that, i was looking for articles but non of them seemed to make much sense...


wnd = reinterpret_cast<Window *>(::GetWindowLong(hwnd, GWL_USERDATA));


seems to make sense although a bit advanced...
thanks for pointing me in the right direction

Share this post


Link to post
Share on other sites
You need to call a static function or a free function, that function can then call the appropriate class member function.

That pretty much sums up what the article Enigma posted says wihtout all the implementation details.

Share this post


Link to post
Share on other sites
what exactly is it that is so special about this function that means you have to create a pointer through some wacky conventions, im sure to professionals it doesnt seem too wacky...

Is it due to the CALLBACK aspect of it or is there some other behind the scene reason why?

Share this post


Link to post
Share on other sites
It's because it is a member function of a class, rather than a freestanding function. Internally they are different (because of the hidden pointer-to-object), and the win32api assumes a freestanding function.

Share this post


Link to post
Share on other sites
It seems wacky becasue the Win32 API is written in C, which has no concept of member pointers.

If it were written in C++ the message function parameter would probably take a function object.

Share this post


Link to post
Share on other sites
oh right, i was going to say, i have made member function pointers before and they have worked ok, however using the same method with this wouldnt allow it to cast...

anyway i will keep greading up on that article, although its a bit confusing as it seems hes writing his own message handling function opposed to using the normal windows one, or i just havent read far enough down yet :D

thanks for the help so far...

Share this post


Link to post
Share on other sites
Be aware that, although Oluseyi doesn't mention it, the SetWindowLong method is dangerous because it's not 64 bit compatible. I tried to use SetWindowLongPtr for the same purpose, but I just couldn't get it to work, and I didn't feel like fighting the Win32 API much longer. So I instead use the same std::map solution as him, but with less sugar coating.

Share this post


Link to post
Share on other sites
so is there no SIMPLE way of keeping it within the class? as if i have it externally i dont have access to the class members/methods from within that function...

the simplest method usually is the safest but in this case it sounds like its too much trouble and too risky keeping it within the class....

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!