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

Started by
29 comments, last by Grofit 18 years, 6 months ago
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
Advertisement
Article.

Enigma
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
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.
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?
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.
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.
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...
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.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
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....

This topic is closed to new replies.

Advertisement