How to incorporate a pImpl Interface while also allowing WndProc to interact with it?

Currently developing a 2-D game-dev environment with a Wrapper/GameEngine class combination in Win32 (C/C++ language). As it stands, I use the Wrapper to set up and initialize all items with the Window as well as to initialize the GameEngine class before entering the message loop.

To do this, I redirect Windows messages sent to WndProc(...) to HandleEvent(...) methods found in both the Wrapper and the GameEngine classes. This is done via static, private shared_ptrs found in the Wrapper class. One such pointer points to the contained GameEngine, and the other points to the Wrapper itself.

An example WndProc function may look like this:

LRESULT CALLBACK WndProc(HWND hWindow, UINT msg, WPARAM wParam, LPARAM lParam)
{
    // Initialize via wrapper, else route to engine
    switch (msg)
    {
        case WM_CREATE:
            return GEN::Wrapper::GetWrapper()->HandleEvent(hWindow, msg, wParam, lParam);
            break;
        default:
            return GEN::Wrapper::GetEngine()->HandleEvent(hWindow, msg, wParam, lParam) // DefWndProc called from this HandleEvent
    }
}

Where GetEngine() and GetWrapper() are static accessor methods that return their respective shared_ptr.

What I'd like to do is incorporate the pImpl idiom in this design. That is, I want to create a wrapper interface class that removes implementation details from the specific wrapper being used. One of the problems ailing me is that I need (or at least think I need) that static accessor method for the Wrapper in question. This is because as I have it each derived Wrapper initializes the window in a game-specific way, and WndProc needs to know where to forward that initial message, as one can see in the code above. Of course, the static method is tied to the wrapper class, so GetWrapper() would be impossible to put into that interface.

Essentially, I want to have the WrapperInterface declared like this:

class WrapperInterface
{
public:
    static std::tr1::shared_ptr<WrapperInterface> // factory function
        create_Wrapper(...); // returns pImpl

    // ... Pure virtuals here                                                               
};

Derive Wrapper publicly from WrapperInterface, and then implement a primitive version of create_Wrapper more or less like this:

std::tr1::shared_ptr<WrapperInterface> WrapperInterface::create_Wrapper(...)
{
    return std::tr1::shared_ptr<WrapperInterface>(new Wrapper(...));
}

so I can put this line in WinMain:

std::tr1::shared_ptr<WrapperInterface>
      Wrapper(WrapperInterface::create(...));

And still have WndProc be able to forward messages to the Interface methods?

Update:

A thought occurred to me to store a static pointer to the WrapperInterface itself and have create_wrapper set that member variable to whatever wrapper the interface is using. I then eliminated Wrapper's static pointer altogether and made the Engine pointer non-static. This somehow feels like cheating, though, as now I'm introducing a private member variable into the interface, albeit a static one. Any thoughts or tips on redesign methods without storing statics would be great!

In any event, thank you all for reading and any advice you may give.

Solution

You can associate a pointer to the actual Wrapper object with the window that it creates for itself. To do that, you can either:

use RegisterClass/Ex() with the cbWndExtra field set to sizeof(Wrapper*) to reserve extra memory inside the HWND, then use SetWindowLong/Ptr() with the nIndex parameter set to 0 to store the Wrapper* pointer value inside the allocated memory:
```
WNDCLASS wc;
wc.lpszClassName = TEXT("MyWrapperWindow");
wc.cbWndExtra = sizeof(Wrapper*);
...
RegisterClass(&wc);
```
```
hwnd = CreateWindow(TEXT("MyWrapperWindow"), ...);
SetWindowLongPtr(hwnd, 0, (LONG_PTR) this);
```

use SetWindowsLong/Ptr() with the nIndex parameter set to GWLP_USERDATA:

hwnd = CreateWindow(...);
SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR) this);

use SetProp() with a custom name in the lpString parameter:

static const LPCTSTR szMyProp = TEXT("MyProp");

hwnd = CreateWindow(...);
SetProp(hwnd, szMyProp, (HANDLE) this);

use SetWindowSubclass() with the Wrapper* pointer passed in its dwRefData parameter:

hwnd = CreateWindow(...);
SetWindowSubclass(hwnd, &MySubClassProc, 1, (DWORD_PTR) this);

In cases 1-3, at least (not sure about case 4), you can alternatively pass the Wrapper* pointer in the lpParam parameter of CreateWindow/Ex() and then call one of the mentioned functions inside your window procedure's WM_NCCREATE or WM_CREATE handler:

hwnd = CreateWindow(..., this);

case WM_CREATE:
{
    Wrapper *pThis = (Wrapper*) ((LPCREATESTRUCT)lParam)->lpCreateParams;
    // SetWindowLongPtr(hwnd, 0, (LONG_PTR) pThis);
    // SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR) pThis);
    // SetProp(hwnd, szMyProp, (HANDLE) pThis);
    break;
}

For all other messages, your window/subclass procedure can extract the Wrapper* pointer when needed. This way, it does not need to use any global statics to hunt for the object:

GetWindowLong/Ptr() with the nIndex parameter set to 0:

Wrapper *pThis = (Wrapper*) GetWindowLongPtr(hwnd, 0);

GetWindowsLong/Ptr() with the nIndex parameter set to GWLP_USERDATA:

Wrapper *pThis = (Wrapper*) GetWindowLongPtr(hwnd, GWLP_USERDATA);

GetProp(), passing the same lpString pointer that was passed to SetProp() (important!):
```
Wrapper *pThis = (Wrapper*) GetProp(hwnd, szMyProp);
```
the subclass procedure's dwRefData parameter:
```
Wrapper *pThis = (Wrapper*) dwRefData;
```