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


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?


I had this problem recently. To get around it and keep all of the code in the class concerned rather than spreading it around the program I had a class static reference count that I incremented before calling RegisterClass(). I then ignored return values of ERROR_CLASS_ALREADY_EXISTS and only called UnregisterClass() in the dtor when the reference count was 0.

This didn't require any locking (use InterlockedIncrement() and InterlockedDecrement() to manage the reference count) and means that uses of the class don't need to know or care that internally the class uses a hidden window.

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.

By : paercebal

Well, you might be able to avoid a call down into the kernel - RegisterClass seems to need to get down there - but window classes are per-process and per-module, so you shouldn't hurt anything by registering a class multiple times.

Given that there aren't generally that many classes, I wouldn't be too surprised to find it was actually implemented as a linked-list. You might get a little gain by looking it up in a hash table, but you'd probably be better off doing it as a simple boolean.

This video can help you solving your question :)
By: admin