Use CallWindowProc when using WNDPROC pointers directly

 

A recurring theme I see while debugging application compatibility issues has to do with the direct use of the window proc pointer. If the intended WNDPROC exists in a DLL that is located in Slot 0, the pointer “looks right” and is often mistakenly used directly. In Windows Mobile, direct access to the window procedure requires you go through CallWindowProc().

 

Instead of trying to use the pointer directly, use CallWindowProc() like this:

 

// Direct call to wndProc()

// Incorrect! tp.result = recvWndClass.lpfnWndProc(NULL, GCI_WNDPROC_TEST_MSG,NULL,NULL);

tp.result = CallWindowProc(recvWndClass.lpfnWndProc, NULL, GCI_WNDPROC_TEST_MSG,NULL,NULL); // Good Job!!

The reason for this indirection has to do with the way proc addresses are tracked by GWE and “mapped” to different processes. Sometimes you can get “lucky” and these addresses will work – but if the DLL you are trying to access is loaded outside of Slot 0, this mapping will break and your application will crash. Using CallWindowProc() abstracts this mapping for you so you don’t have to worry about it. Please see the WM documentation for Get/SetWindowLong() as well as other WM WNDPROC API’s for more information.

Comments

• Anonymous
  April 02, 2008
  ٍSome incidents i saw related to calling original window proc, is when two applications subclass a single window from two different processes. if the message parameters contain pointers, it seems that CallWindowProc switch the application context before calling the window proc. so the subclass procedure should map the pointer accordingly. i saw that in many cases such as EM_REPLACESEL editor message.