🚀 go-pugleaf

jls@hsv3.UUCP (James Seidman) writes:


>I'm trying to create a child window which can tell when the cursor goes in
>or out of it.  The state of the window needs to be different depending on
>whether or not the cursor is currently inside it.

>Now, figuring out when the mouse is inside it is easy, by capturing
>WM_MOUSEMOVE.  However, figuring out when the mouse leaves the window
>is harder. 

Hi!

You could try polling the mouse with GetCursorPos() within the application's
message loop, and check whether the cursor is inside the desired child window
by calling WindowFromPoint() .  If it were, you could act directly, or, more
elegantly, send that window a self-defined WM_USER message with wParam set to
indicate cursor entering / exiting status when the hWnd returned by Window-
FromPoint() has changed.

This could also be made as a DLL were there a need to cooperate among many
instances of the same application.  The DLL would contain a 'windowless' 
process to poll the mouse position and two functions which the application
uses to register a window being checked + the corresponding event handler,
and to un-register the service before the application terminates.

Terveisin: Risto Lankinen
-- 
Risto Lankinen / product specialist ***************************************
Nokia Data Systems, Technology Dept *  2                              2   *
THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME!  Now working on 2 +1 *
replies: risto@yj.data.nokia.fi     ***************************************

risto@tuura.UUCP (Risto Lankinen) writes:
>You could try polling the mouse with GetCursorPos() within the application's
>message loop, and check whether the cursor is inside the desired child window
>by calling WindowFromPoint() .  If it were, you could act directly, or, more
>elegantly, send that window a self-defined WM_USER message with wParam set to
>indicate cursor entering / exiting status when the hWnd returned by Window-
>FromPoint() has changed.

I'm already doing something of the sort in the parent on WM_MOUSEMOVE,
WM_SETCURSOR, and WM_KILLFOCUS.  But none of these help when the user
moves the mouse outside of the parent window fast enough that no messages
get generated in the parent area outside of the child window.

Now, I could use a timer to poll periodically, but this seems like a
terribly inelegant solution.  I was hoping that there would be something
a little nicer to solve the problem (but I'm rapidly losing hope...)

I would like to bring up a new topic of discussion; I think there might be
a serious flaw in Windows as we know it.

I refer to the lack of installable device drivers *for windows*. I know
that we can communicate to devices by using DOS to load the device drivers,
and then try and use the device driver interface from Windows apps. However,
there are at least two drawbacks to this:

1) Windows itself knows nothing about the device driver. A glaring example
   is the hard disk - the code to access the hard drive is hard coded into
   windows (I think), and the only thing you can do is turn virtualHDIRQ off,
   in which case it goes through BIOS. Would it not have been better if
   instead there were a well defined device driver interface, and windows
   came with a default one? That way, people could get a device driver for
   their whiz bang HD and get super performance out of it.
2) DOS device drivers take up space in the lower 1 Meg. This takes off
   space from every dos window I run. Consider the case of a windows device
   driver for a network card - if I loaded this "device driver" while
   initializing windows, I wouldn't need to have the device driver take up
   space in every DOS window. Additionally, windows apps would be able to 
   properly share the resources etc.

In general, I look upon windows as an operating system (what else do you
call something that provides memory, time and other resource management?).
But I have never heard anything about an *installable* device driver for
windows - true, there are the standard drivers like mouse.drv and sound.drv,
but nothing about installable device drivers for any arbitrary piece of
hardware.

But then again, perhaps I am missing something big - perhaps the DDK does
allow you to write device drivers for your own piece of hardware.

Comments?

Milan.

In article <5538@hsv3.UUCP> jls@hsv3.UUCP (James Seidman) writes:
>
>I'm trying to create a child window which can tell when the cursor goes in
>or out of it.  The state of the window needs to be different depending on
>whether or not the cursor is currently inside it.
>

Have you thought of setting a system hook?  WH_GETMESSAGE looks like the 
best bet for what you are trying to do.  This would let you monitor mouse 
movements on a system wide basis.


Brian Farmer

In article <823@tuura.UUCP> risto@tuura.UUCP (Risto Lankinen) writes:
>jls@hsv3.UUCP (James Seidman) writes:
>
>
>>I'm trying to create a child window which can tell when the cursor goes in
>>or out of it.  The state of the window needs to be different depending on
>>whether or not the cursor is currently inside it.
>
>>Now, figuring out when the mouse is inside it is easy, by capturing
>>WM_MOUSEMOVE.  However, figuring out when the mouse leaves the window
>>is harder. 

Seems to me that whenever your child window gets the WM_MOUSEMOVE
message you could capture the mouse (using SetCapture(hwndchild)). 
This would cause all mouse messages to go to your window regardless of
where the mouse is.  Now, when the mouse moves outside your window
rectangle, you simply release the capture.

--Dave

davidds@microsoft.UUCP (David D'SOUZA) writes:
>In article <823@tuura.UUCP> risto@tuura.UUCP (Risto Lankinen) writes:
>Seems to me that whenever your child window gets the WM_MOUSEMOVE
>message you could capture the mouse (using SetCapture(hwndchild)). 
>This would cause all mouse messages to go to your window regardless of
>where the mouse is.  Now, when the mouse moves outside your window
>rectangle, you simply release the capture.

I thought of this too, and actually tried it.  The problem is that then,
whenever the cursor is inside my child window, the user can't switch away
from it using the normal magic keys (alt-enter, control-escape, etc.).
While this is acceptable for the usual uses of SetCapture (which usually
involve the user making a selection, having a mouse button down, or the
like), it's really unacceptable here.

-- 
Jim Seidman, Headland Technology, 46221 Landing Parkway, Fremont CA 94538
The Doctor: It was a terrible babble of inhuman voices.
Prof. Chronotis: Oh, that was just the undergraduates!
							- Doctor Who, "Shada"