WinAPI - how to organize lots of HWND objects?

Question

As I push forward my first winapi UI, I find myself creating large, uncomfortable stacks of HWND variables in my WinMain file:

HWND foo;
HWND bar;
HWND baz;
HWND etc;

int WINAPI WinMain(...) {}

Of course, these variables are used in the functions in the rest of the file - the message loop, for example - so they must be accessible.

For my relatively small UI, I'll have something like 30 HWNDs piled up so they're in a visible scope. This makes me very suspicious that I'm doing it wrong.

Is this what should be happening, or is there a more practical way to organize this?

Answer 1

You have a few solutions, depending what your program is.

1. You can put all those handles in one or many containers like std::vector.
2. You can map them like chris suggests.
3. If your program gets big, you might want to organize them into logical units. For example, if 15 of those windows are for one half of your logic and the other 15 for another half (say controls inside tabs) then you might want to group those controls in some way (file, class, whatever is the most logical fit).

Answer 2

You only need one HWND in your main program, and that's for a main window.

The API doesn't require a single main window, but that's most common. And even when from a user point of view the application offers several apparently independent windows, it's a good idea to have a main window in the program (it can be invisible, but provide grouping).

The other windows are then either children of the main window (within it), or windows "owned" by the main window. In general. And in particular for a first ever Windows program. :-) So you don't need separate variables for these windows. Whenever a window should react to something, that's a message to the window, which means a call of one your functions with the relevant window handle as argument.

Every child window can have a unique integer ID, and that's one way to keep track of them.

But as you get ahead you will want to associate state with each window, and the easiest way to do that is to use the Windows "subclassing" API to associate a pointer with each window. Then you can route window procedure calls to a method on an associated C++ object. Where different messages can be routed further to different message handling methods, each with access to window's state (it's just this C++ object).