Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!emory!hubcap!ncrcae!PEDEV!rogerson
From: rogerson@PEDEV.Columbia.NCR.COM (Dale Rogerson)
Newsgroups: comp.windows.ms
Subject: Re: Petzold's HexCalc
Message-ID: <3231@PEDEV.Columbia.NCR.COM>
Date: 23 Aug 90 17:46:29 GMT
References: <674@dbase.A-T.COM> <779@venice.SEDD.TRW.COM>
Reply-To: rogerson@PEDEV.Columbia.NCR.COM (Dale Rogerson)
Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
Lines: 34

In article <779@venice.SEDD.TRW.COM> press@venice.sedd.trw.com (Barry Press) writes:
>Yea, verily.  For instance, here's another one.  It used to be that you could
>use the hPrevInstance parameter passed to WinMain to see if another copy of
>the app was running, and if you chose to only allow one to run exit if it was
>non-zero.  You can't do that any more.  hPrevInstance seems to hang around 
>non-zero for at least a while(standard mode for the instances I'm seeing) after
>the previous copy is terminated.  You also have to pay attention to the change
>that a second RegisterClass call while the class still exists (e.g. if
>hPrevInstance is non-zero) will FAIL.

I ran into some of these problems with my "practice" C++ class library. 
Ideally, I would like to be able to create a window with something like:
	SimpleWindow myWind;
I would hope that this would do all of the needed Class registration in the
contructor.  One thing a good Windows class library should do is remove some
of the "order" specific requirements of Windows programming.  So I do not
want to require the user of the SimpleWindow class to only create windows
in the WinMain section of the program and also check hPrevInstance.  Even
if the constructor checks the hPrevInstance variable, it is only valid during
WinMain.

The solution I am using is to call the Windows function: 
	BOOL GetClassInfo( hInstance, lpClassName, lpWndClass );
	// This is from memory so check your 3.0 SDK.
This function will get the WNDCLASS memory structure with the class name
pointer to by lpClassName and place it into the lpWndClass buffer.  It
returns FALSE if it can't find the class. 

This should make up for some of the problems with hInstance.
I have not seen the other problem you mentioned with hPrevInstance staying
non-zero. I will have to look into this.

-----Dale
	Rogerson-----