Here's the problem: Create a self-contained class for any one of many types of winapi functions. Catch: the callback is a member function.

The issue is the stack produced by the type of call. The solution is probably achieved through binding/similar mechanism.

Traditional std::mem_fun doesn't work. boost::mem_fn can actually handle the callback and its quirks. The problem is actually passing it if i'm using boost.
Windows expects a DWORD_PTR (foolishly tried casting which failed to compile) but i've also seen people cast as DWORD (quite nasty).

Currently I have a singleton class.. the callback is static. This is fine for this class because it IS a singleton by nature. But soon i will need to make a non-singleton class with the same problem.

I've google this so far and haven't found much. I've found a thunking technique which is basically an assembly hack.. mfc uses that.

Maybe i should pick up myself that book from the apple commercial "C++ gui programming". I can see why you'd need it

map<DWORD, void*> pointerLookup;

Pretty simple, when you think about it.

Yup. And WORD on MSVC is 16-bit, so DWORD is double that.. 32-bit. Not sure how DWORD_PTR is handled on 64-bit targets, though.

However, for C callbacks with non-static C++ methods, the funciton needs to take a user-pointer to pass along to the callback you give it, then give it a static callback and pass 'this' as the user-pointer. Then in the static callback, cast the user-pointer to the class type, and call the non-static member.

class SomeClass {
   real_callback()
   {
      ...
   }

   some_static_callback(void *ptr)
   {
      static_cast<SomeClass*>(ptr)->real_callback();
   }

   foo()
   {
      SetSomeWin32Callback(some_static_callback, this);
   }

Though if you can't pass 'this' for a user pointer, then you're out of luck.

Well the issue here is that say you have this (although true of any C++ class wrapping any winapi object).

The callback is a member function of a class. A standard c-callback in WINAPI uses __stdcall (that's what CALLBACK is defined to be). Problems.. well in C++ there is a hidden "this" parameter added to every member function call. And in C++ if you use polymorphism or anything fancier it's even more broken.

So my first misguided attempt was to try and wrap that call with mem_fn, mem_fun, etc.. But those create a struct with an overloaded () operator. This does not fix anything.

What i will try is to make a static function. Inside it I will have a map<HANDLE, CWindow*>. That map will be static. I will then call the appropriate function then.

Do you know there are a couple of extensive documents on the intarwebs that go thru this procedure (wrapping win32 api)? If you're just inventing a wheel that's great, I think it's a horrible waste of time though.....

Tobias FTW!!!

  static LRESULT CALLBACK staticCallback (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
  {
    CWindow* instance = reinterpret_cast<CWindow*>(GetWindowLongPtr(hwnd, DWLP_USER));

    return instance->WindowProcedure(hwnd, message, wParam, lParam);
  }

Cookies to tobias

Gillius: I've used C# winforms lots. I find it quite retarded how there's no built-in printing for text boxes, hardware accelerated blitting (gdi+ is all software based!) and how rich text box is absolutely useless because of the font attribute rules.
troll--

edit: just realized that while most buttons etc. are handle based there are also timers, waveIn, waveOut, ..etc I will have to look into that. I guess i just got exited there was a simple solution. Most of the crud on the net involved "thunk" and other crude hacks (not sure how portable that is.. its essentially an assembly hack). This technique though seems to have promise. Otherwise i guess i could still use a map for other structs.