My Opinion on pointing WndProc to member functions of the class, wndproc points

My Opinion on pointing WndProc to member functions of the class, wndproc points

I used to think about how to call Windows APIs such as WNDCLASS and CreateThread in the class and how to use the member function address when passing in the function parameter address. For research, I wrote an example code:

#include <iostream>#include <stdio.h>using namespace std;typedef int (__stdcall *XSSH_SAY_HELLO)(int);class XTestMethod{typedef int (__stdcall XTestMethod::*XSayHello)(int);public:XSayHello say;int hi;public:XTestMethod();virtual ~XTestMethod();int sayhello(int arg);};XTestMethod::XTestMethod(){say=&XTestMethod::sayhello;hi=1000;}XTestMethod::~XTestMethod(){}int XTestMethod::sayhello(int arg){printf("\r\nsay:%d%d\r\n",arg,this->hi);}int main(int argc, char *argv[]){XTestMethod t;XSSH_SAY_HELLO call=*(XSSH_SAY_HELLO*)&t.say;call(0);system("pause");return 0;}

During debugging, it is found that the this pointer in the stack is empty before calling the class members. After the input, the value of the output result is random, and the latter directly leads to an error (empty reference ).

For member functions and member variables, the offset addresses of the same member variables of different objects of the same type are the same. When accessing member variables, their addresses are calculated based on the overlapping object addresses, if you use the preceding method to access the member function and then ask the Member variable, an error occurs. Even if the object pointer is pushed into the stack before accessing the member variable, we should not only consider the address of the object to be pushed into, but also use the member function as a global function, it is no different from the purpose of using static member functions and loses the meaning of the facial object.

How do vc ++ WndProc parameters pass to class member functions?

It's easy, just like a normal function.

WndProc

WndProc is not directly called in WinMain, but is indirectly called. The following message loop is often called the main message loop, which is the root cause of Win32 program driver. All Win32 programs have similar loops (MFC is no exception, in CWinThread :: run function ):

MSG msg;
While (GetMessage (& msg, NULL, 0, 0 ))
{
TranslateMessage (& msg );
DispatchMessage (& msg );
}

Your WndProc seems to have nothing to do with the above Code, but the secret is in the DispatchMessage. This function serves the same purpose as its name and is used for message distribution, all window handles correspond to a window process function, and the window handle of each message is saved in This MSG structure. Although the source code of DispatchMessage is not public, it is almost certain that, he first calls the Windows API function GetWindowLongPtr and adds the GWLP_WNDPROC parameter to obtain the window function pointer corresponding to the window handle. Then he calls this window function. Therefore, the window function is indirectly called by the main message loop. When the window handle in the MSG structure obtained by GetMessage is NULL, DispatchMessage does not call any window procedure function.