marco@hpmcaa.mcm.hp.com (Marco Dalla-Gasperina) (12/28/89)
Greetings, I'm having a problem registering a window class inside a DLL... It seems to work for a "few" times (usually 3) but then it fails? The RegisterClass call is inside the LibInit routine that gets called at load time (as shown in Petzold ch. 18). The return value of LibInit is tied to the success of the RegisterClass. If the RegisterClass fails, LibInit returns 0 back to Windows at which time the spawn fails due to "Not Enough Memory". Numerous tests have confirmed that this is the case, but I could be missing something. Any ideas? BTW, by symmetry, I would expect a LibUninit call also... does such a beast exist? Just Curious. Thanks, marco
bobg@mirror.UUCP (Bob Goodearl) (12/30/89)
In article <6970014@hpmcaa.mcm.hp.com> marco@hpmcaa.mcm.hp.com (Marco Dalla-Gasperina) writes: =>I'm having a problem registering a window class inside a DLL... It seems =>to work for a "few" times (usually 3) but then it fails? => When writing DLL code, I found that a window class registered using the DLL instance handle caused problems. If the application calling the DLL was closed and then started a second time without exiting windows first, the call to RegisterClass in the DLL would fail the second time. The solution I found was to use the parent application's instance handle when calling RegisterClass in the DLL. This works for the code I'm writing because only 1 application can use the DLL and only 1 instance of the application can exist at any one time. Along the way, I tried bypassing RegisterClass if the DLL had been initialized previously, but then the call to CreateWindow failed when using that class. Hope this is of some use to you. === Bob
michaelt@microsoft.UUCP (Michael THURLKILL) (01/03/90)
In article <34458@mirror.UUCP> bobg@mirror.TMC.COM (Bob Goodearl) writes: >In article <6970014@hpmcaa.mcm.hp.com> marco@hpmcaa.mcm.hp.com > (Marco Dalla-Gasperina) writes: >=>I'm having a problem registering a window class inside a DLL... It seems >=>to work for a "few" times (usually 3) but then it fails? >=> > >When writing DLL code, I found that a window class registered using the >DLL instance handle caused problems. If the application calling the >DLL was closed and then started a second time without exiting windows >first, the call to RegisterClass in the DLL would fail the second time. >The solution I found was to use the parent application's instance >handle when calling RegisterClass in the DLL. This works for the code >I'm writing because only 1 application can use the DLL and only 1 >instance of the application can exist at any one time. > The problem is that the class isn't automatically de-registered when the DLL exits, and it is not possible to request that the class be de-registered. Things will work ok in the case of using hInst of the app because the class then "belongs" to the task and goes away when the task terminates. However, if more than one app uses the class, and the first app terminates, the class is destroyed, and the other apps will shortly crash. A class can be registered, and shared by applications, if it is registered in the DLL, uses the DLL's hInst, AND the DLL stays around forever. To keep the DLL around, it must be loaded independantly, ie. file-run from the MSDOS Executive or placed on the load= line in win.ini. This is one of those things that "is under consideration and will be addressed in a future release." But seriously, I think it will be fixed. Mike Thurlkill Disclaimer: These thoughts and opinions are mine. They should not be mis-construed as being correct or in any way related to my employer.