Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncr-sd!iss-rb!booboo!davel
From: davel@booboo.SanDiego.NCR.COM (David Lord)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Associating window handle with C++ object
Message-ID: <1991Apr18.182959.11263@SanDiego.NCR.COM>
Date: 18 Apr 91 18:29:59 GMT
References: <0J7H11w163w@burklabs>
Sender: @SanDiego.NCR.COM
Reply-To: davel@booboo.SanDiego.NCR.COM (David Lord)
Organization: NCR Corporation, Rancho Bernardo
Lines: 55

In article <0J7H11w163w@burklabs> ronb@burklabs (Ron Burk       ) writes:
>
>Unfortunately, CreateWindow() will send messages to the window before it
>returns the window handle, so the scheme just described doesn't quite
>work.  In the "whello.cpp" that comes with Borland C++, they assume that
>any "extra" window bytes will be initialized to zero.  When their Window
>constructor calls CreateWindow(), it passes "this" in the last
>parameter.  In their single window function, they first extract the
>"this" pointer from the "extra" window bytes and if it is zero and the
>message is WM_PAINT, they get the "this" pointer from
>lParam->lpCreateParams and store it in the window "extra" bytes. 
>
>How do other C++ classes associate the window handle with the C++ window
>object? Is it safe to assume that WM_PAINT is the first message received
>by any window created by CreateWindow()?

I've played with this problem quite a bit and here's some of the things
I found:

	I didn't like the tecnique used in whello.cpp. Seems to me their
	use of classes serves only to make the program more complicated
	and doesn't give coresponding benifits (reusibility, etc.)

	Ultimately I used a separate window proc for each window. One
	reason is that I didn't want to stray too far from what I would
	be seeing in every example in the reference books. The results
	also seemed much clearer (to me) than what was done in whello.cpp.

	So far I have classes:

		classWindow
		classWChild : classWindow
		classWDlgModal : classWindow
		classWDlgModless : classWindow
		classScrollBar
		classScrollBarCaptioned : classScrollBar
		   (this one scrolls a second window in sync with the one
		   containing the scroll bar.)

	There are a lot of messages that get sent to your window before
	CreateWindow returns. I tried setting the handle in WM_CREATE
	which seemed like the obvious place to me but I still had problems
	with some of the non-client messages that come before WM_CREATE.
	As far as I can tell, the best thing is to use the hWnd that
	gets passed in as a parameter any time you call DefWinProc (or
	whatever it's called) I think there were other messages that I
	was handling that also came befor WM_CREATE. I suppose another
	solution is to start out with your handle set to some invalid
	value and set it on the first message received, regardless of
	what message it is.

	I'd be interested in hearing any other approaches.

--
Dave.Lord@SanDiego.NCR.COM