Home/ Questions/Q 843343
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T06:06:40+00:00

There is a simple WinAPI application. All it does currently is this: register a

  • 0

There is a simple WinAPI application. All it does currently is this:

  • register a window class
  • register a tray icon with a menu
  • create a value in the registry in order to autostart
  • and finally, it checks if it’s unique using a mutex

As I’m used to writing code mainly in C++, and no MFC is allowed, I’m forced to encapsulate this into C++ classes somehow. So far I’ve come up with such a design:

  • there is a class that represents the application
  • it keeps all the wndclass, hinstance, etc variables, where the hinstance is passed as a constructor parameter as well as the icmdshow and others (see WinMain prototype)
  • it has functions for registering the window class, tray icon, reigstry information
  • it encapsulates the message loop in a function

In WinMain, the following is done:

Application app(hInstance, szCmdLIne, iCmdShow);
return app.exec();

and the constructor does the following:

registerClass();
registerTray();
registerAutostart();

So far so good. Now the question is : how do I create the window procedure (must be static, as it’s a c-style pointer to a function) AND keep track of what the application object is, that is, keep a pointer to an Application around.

The main question is : is this how it’s usually done? Am I complicating things too much? Is it fine to pass hInstance as a parameter to the Application constructor? And where’s the WndProc?

Maybe WndProc should be outside of class and the Application pointer be global? Then WndProc invokes Application methods in response to various events.

There’s one more possible solution : make the application class a singleton. Then it’s trivial to obtain the handle to that object from the WndProc.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The answer is SetWindowLongPtr. It allows you to associate a void* with a given hWnd. Then, in the WndProc, you just extract said void*, cast, and call the member method. Problemo solvo. There’s a few ups/downs with SetWindowLongPtr, you must call some other function to see the effects or somesuch BS, and Windows sends messages before CreateWindowEx returns, so you must be prepared for GetWindowLongPtr(hWnd, GWL_USERDATA) to return NULL.

    This of course means that for a given WindowProc, all instances that use it must have a common interface, since there’s not much you can do with a void*.

    And, yes, it’s fine to pass HINSTANCE to the App constructor. I’ve seen samples that do something strange to avoid this but I never made it work myself.

    Edit:
    Don’t confuse Get/SetWindowLong with Get/SetWindowLongPtr. Get/SetWindowLong is deprecated and unsafe.

    • 0