Article: WNDPROC Thunks - Comments Please

Talliesin

WNDPROC Thunks

If you ever program classes for controlling Windows™ windows you will have met with the task of associating windows messages with the correct instance of the class. There are a few alternative ways of doing so. This document outlines one method using self-modifying code which is fast, efficient, reliable, unlikely to interfer with other code (including code from other users of the same window). Most importantly, in my opinion, it's a technique that largely stays out of your way once it is in place.

Comments please.

silverside

looks like you know what you're talking about alright

however it seems unneccesarily complicated to me

I'd usually know which type of window i'd be sending each message to, then wrap any extra information into the WPARAM and LPARAM pointers, just casting them back to a pThis or pDataBlock and doing a switch in the WndProc (actually using MFC and the ON_USER_MESSAGE or ON_REGISTERED_MESSAGE macros)

Can you summarise in a couple of sentences why you would need to use such an approach in practice?

Talliesin

Originally posted by silverside
however it seems unneccesarily complicated to me

Well it's very reusable code. To actually reuse it you just need to call the constructor with the object and function pointers. As I said, I'd rather to one really complicated thing once than a slightly complicated thing dozens of times.

I'd usually know which type of window i'd be sending each message to, then wrap any extra information into the WPARAM and LPARAM pointers, just casting them back to a pThis or pDataBlock and doing a switch in the WndProc (actually using MFC and the ON_USER_MESSAGE or ON_REGISTERED_MESSAGE macros)

This isn't about sending messages, it's about processing them. Windows doesn't know much about what window it's sending WM_VSCROLL (for example) to, and knows less about what C++ class you are using to handle it.

As for ON_REGISTERED_MESSAGE and the rest of MFC's message-handling system, they are implemented by something in MFC receiving the raw message, and then working out what object to send it to (possibly using exactly this technique, possibly using one of the others I mentioned). I know that ATL's equivalent does use this technique (after all I admit that I copied the machine code used from ATL's version).

Can you summarise in a couple of sentences why you would need to use such an approach in practice?

If you have a HWND and need an object pointer you'll use one of the techniques I mention. I favour this one.
You'll be in this situation if either you aren't using MFC, ATL or similar. This may be the case for few reasons:

1. You just don't like MFC
2. You are porting from something else and rolling your own is a more "natural" translation (VB that makes heavy use of the API generally translates to such classes more naturally than MFC classes).
3. You are experimenting with relatively "raw" ways of doing stuff as a learning experience (it's always good to experiment with stuff a little bit lower-level than you generally use).
4. You want to know what's going on behind the scenes with ATL (or MFC, though I don't know if this is the method MFC uses).

Talliesin

Just did a search to see if MFC does use this technique or not. It uses, or used - maybe this is only with an older version - a map associating handles with pointers (the fourth of the four other ways of doing the handle to pointer translation that I mentioned in the article). http://www.microsoft.com/msj/0997/c0997.aspx gives details.

Still the fact that MFC has to do this to make your ON_REGISTERED_MESSAGE work shows that some mechanism like this is necessary somewhere in the code.