🚀 go-pugleaf

In article <0J7H11w163w@burklabs>, ronb@burklabs (Ron Burk       ) writes...
>Suppose you are creating a C++ class which corresponds to a Windows 3.0
>window.  Obviously, you will want to associate a Windows 3.0 window
>handle with the C++ window object.  I would think the most natural way
>to do this would be:
> 
>a) Allocate enough "extra" bytes to hold a pointer to "this" when you
>   register your window class.
> 
>b) Using a single window function for all windows.
> 
>c) In your single window function, extract the "this" pointer and pass
>   the window message on to the correct C++ window object.
> 
>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()?

Being a novice Windows programmer (working my way through the Petzold book) and
having the BC++ examples and the Borland Languages Express (or some such name)
to work from I am cobbling together my own class library. I currently assume
that WM_CREATE is going to be the first Windows message I care about (can't do
much until you have created the window) and grab the pointer from
lpCreateParams there. I also have gotten rid of the switch statements from hell
in my code by encapsulating that functionality into a base class which does all
the messy stuff. I define virtual functions for all the WM_* messages, VK_*
messages, and SB_* messages. Now all I have to do is derive a class from Window
and define the routines I need to reimplement (at least wmPaint) and I have a
usable class without any distracting ugliness. I don't have many of the WM_*
calls implemented yet (I'm only in chapter 3 of Petzold), but, I have all the
VK_* and SB_* stuff done.

BTW, this code also supports multiple Windows sharing a common application. All
you do is create a new object and voila, another window goes up.

If anyone is interested, I can mail you the class code (it is quite large and
broken up over several files). However, don't expect it soon as I am on the
road next week.

---
Barry L. Wallis			USENET: wallis@labc.dec.com
Database Consultant		Prodigy (don't laugh): DNMX41A
U.S. DECtp Resource Center	DECUServe: EISNER::WALLIS (not on the net yet)
Los Angeles, CA			"No one voted for me, I represent myself"
---