Side effects of calling RegisterWindow multiple times with same window class?

Question

I'm working on a little test application at the minute and I have multiple window objects floating around and they each call RegisterWindowEx with the same WNDCLASSEX structure (mainly because they are all an instance of the same class).

The first one registers ok, then multiple ones fail, saying class already registered - as expected.

My question is - is this bad? I was thinking of using a hash table to store the ATOM results in, to look up before calling RegisterWindow, but it seems Windows does this already?

Answer 1

If your window class is defined in a DLL

Perhaps you should call your RegisterClass() in the PROCESS_ATTACH part of the DllMain, and call your UnregisterClass() in the PROCESS_DETACH part of the DllMain

If your window class is defined in the executable

Perhaps you should call your RegisterClass() in the main, before the message loop, and call your UnregisterClass() in the main, after the message loop.

Registering in an object constructor would be a mistake

Because you would, by reflex, clean it in the destructor. Should one of your window be destroyed, the destructor will be called and... If you have other windows floating around...

And using global data to count the number of active registration will need proper synchronisation to be sure your code is thread-friendly, if not thread-safe.

Why in the main/DllMain?

Because you're registering some kind of global object (at least, for your process). So it makes sense to have it initialized in a "global way", that is either in the main or in the DllMain.

Why it is not so evil?

Because Windows will not fail just because you did register it more than once.

A clean code would have used GetClassInfo() to ask if the class was already registered.

But again, Windows won't crash (for this reason, at least).

You can even avoid unregistering the window class, as Windows will clean them away when the process will end. I saw conflicting info on MSDN blogs on the subject (two years ago... don't ask me to find the info again).

Why it is evil anyway?

My personal viewpoint is that you should cleanly handle your resources, that is allocate them once, and deallocate them once. Just because Win32 will clean leaking memory should not stop you from freeing your dynamically allocated memory. The same goes for window classes.

Answer 2

You can test if the window class was previously registered calling GetClassInfoEx.

If the function finds a matching class and successfully copies the data, the return value is nonzero.

http://msdn.microsoft.com/en-us/library/ms633579(VS.85).aspx

This way you can conditionally register the window class based on the return of GetClassInfoEx.