Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!umd5!brianf
From: brianf@umd5.umd.edu (Brian Farmer)
Newsgroups: comp.windows.ms
Subject: Re: StillDown(), children, XOR mode
Keywords: Mac-->Windows learning curve
Message-ID: <7254@umd5.umd.edu>
Date: 6 Sep 90 20:43:50 GMT
References: <697@dbase.A-T.COM>
Reply-To: brianf@umd5.umd.edu (Brian Farmer)
Organization: University of Maryland, College Park
Lines: 29

In article <697@dbase.A-T.COM> awd@dbase.A-T.COM (Alastair Dallas) writes:

>
>Imagine my surprise to find nothing like StillDown() in the Windows API.
>Fine, I thought, I'll suffice with something like Button().  But it's not
>there, either.  I ended up using PeekMessage(...WM_LBUTTONUP, WM_LBUTTONUP...).
>First question: is this the preferred StillDown() approach?

For the most part yes, but you should be peeking on WM_MOUSEFIRST to
WM_MOUSELAST.  On the WM_MOUSEMOVE message you should be doing your
erasing  and drawing.  The windows receiving the WM_LBUTTONDOWN message 
should issue a SetCapture call to grab ownership of the mouse when it 
moves over other windows.


>window (mouse movement can occur in either child window).  However, getting
>the DC for the parent and trying to draw there is apparently drawing
>invisibly _behind_ the children.
>

If you don't include the window style WS_CLIPCHILDREN when you create the
parent, drawing on the parent should be appear in the child windows where 
they over lap.



Hope this helps,
Brian Farmer
brianf@umd5.umd.edu