The right approach: RegisterClassEx, libraries and leaking resources
Pelle
sorry for double-posting. This is basically a copy from comp.os.ms-
windows.programmer.win32, but I thought it might find an open ear
here, too.
I have read a few articles on groups about problems with
RegisterClassEx and dynamic unloading of DLLs. What I am facing right
now is very similar, though not identical to what I have seen.
A bit of background:
I am trying to build an "internal API" on an OEM-API to simplify the
usage of it and (at a later stage) allow to branch into different
external APIs depending on environment. The OEM-API I am talking
about
uses window-messages to communicate all changes and events internal
to
the OEM API (and of interest to the user). Because my own interface
to
this API doesn't use windows, I am forced to use a hidden window to
do
all the communications with the OEM-API and handle the results as
necessary.
Thus I need to register a window-class for that hidden window.
This is where the problem seems to start...
When I called RegisterClassEx for the first time, it produced an ATOM
just as expected. As typical for development, something else went
astray and I needed to close my test-application and start again.
However, any further approach to RegisterClassEx with the same
parameters failed and GetLastError revealed
"ERROR_CLASS_ALREADY_EXISTS".
This is somewhat confusing. Though I know of the problem of classes
not being unregistered if a DLL unloads, I have always assumed that
the class will be unregistered when the application itself is ended.
Also for all I can tell there's always a chance that something goes
wrong in a way that prevents me to clean-up properly - meaning I fail
to unregister the class during cleanup. In such a case, how can I
make
sure that I'll be able to start my interface regardless? I'll need to
achieve high reliability once I'm done with this...
And when I'm already at asking questions... can someone tell me how
to
get at the class atom when there's no window for the class? I've
tried
FindAtom(LPCSTR) without success (giving it the lpszClassName from
WNDCLASSEX structure). Result was ERROR_FILE_NOT_FOUND.
Please let me know what other information you need to help.
Thanks in advance,
regards,
Pelle.
Pelle
sorry to have bothered you with this question. It happens to me every
once in a while that after putting the problem to the public I
finally
get the key to unravel the knot. However, I'm pretty sure it would
have been much more difficult for me if I had not taken the time to
phrase and sort it.
It turned out that I had inadvertently created a loop, which caused
the RegisterClassEx to be called twice. So right now there's no
problem anymore.
However, if you feel inclined, I'd still be curious on how to make
sure the cleanup is done properly in case the calling application
feels the need to shut down my interface and restart. Since I might
be
out of the ordinary processing stream, this ought to be pretty much
fail-safe.
Thanks,
Pelle.