Re: GetClassInfoEx( ) fails in a DLL
Ron Francis wrote:
Is it OK to store static variables like an ATOM and a pointer to a =
in a DLL?
Is it OK to call UnregisterClass in DLL_PROCESS_DETACH ?
I'm not sure, but note that it's usually not necessary to call =
UnregisterClass at all.
Just on that point, if there were multiple processes attached, would I =
to implement a counter to determine when to unregister the class?
No. RegisterClass and UnregisterClass are per-process.
I would like to register a class based on the 'Edit' class and have =
window procedure in the DLL.
Should the pointer to the window procedure be static?
Why do you need a pointer to a window procedure in a separate variable, =
static or otherwise? I guess I don't understand the question, it doesn't =
make much sense to me.
I don't really like the idea of having to initialize from an EXE, so =
it be reasonable practice to initialize on the first call to a =
set a bool so it only gets initialized once?
Beware of concurrent calls from multiple threads.
With best wishes,
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925