How to capture mouse enter and exit events

Nikhil Kothari

unread,

Sep 23, 1996, 3:00:00 AM9/23/96

to

Hi,

I would like to do some processing whenever
the mouse enters into my window and whenever it
leaves it. (Not just when the window recieves a mouse
click, but whenever it wanders over the window on the
screen).

I couldn't find any mouse events that would
help me deduce when this happens.

Could someone help? Or maybe theres a
sample somewhere.

Thanks
=======================================
Nikhil Kothari
Information and Computer Science,
University of California, Irvine

--> http://www.ics.uci.edu/~nkothari/activex
=======================================

Norman Bullen

unread,

Sep 23, 1996, 3:00:00 AM9/23/96

to nkot...@ics.uci.edu

The first mouse message that you receive, WM_MOUSEMOVE, WM_xBUTTONDOWN,
WM_xBUTTONUP, etc. will let you know (probably) as soon as the cursor
enters your window. If you then use SetCapture you will receive all
mouse messages including the first one after the the cursor leaves your
window. At that point you use ReleaseCapture to let the system control
the mouse once more.

The reason I said "probably" above is that you will not see the mouse
enter your window if some other application has already captured the
mouse. You will have to get a little more fancy if you want to get
around that problem.

Norm

Rainer Strassner

unread,

Sep 24, 1996, 3:00:00 AM9/24/96

to

Nikhil Kothari <nkot...@ics.uci.edu> wrote in article
<01bba8f7$5566a780$21f4...@uci.edu.uci.edu>...

> Hi,
>
> I would like to do some processing whenever
> the mouse enters into my window and whenever it
> leaves it. (Not just when the window recieves a mouse
> click, but whenever it wanders over the window on the
> screen).
>

First you have to capture the mouse in this window. Then catch the
WM_NCMOUSEMOVE - Message. If it comes up first the mouse is leaving the
window.
With the first WM_MOUSEMOVE the mouse enters the window again.

Valery Pryamikov

unread,

Sep 24, 1996, 3:00:00 AM9/24/96

to

Norman Bullen <nbu...@ix.netcom.com> wrote in article

>
> The first mouse message that you receive, WM_MOUSEMOVE, WM_xBUTTONDOWN,
> WM_xBUTTONUP, etc. will let you know (probably) as soon as the cursor
> enters your window. If you then use SetCapture you will receive all
> mouse messages including the first one after the the cursor leaves your
> window. At that point you use ReleaseCapture to let the system control
> the mouse once more.
>
> The reason I said "probably" above is that you will not see the mouse
> enter your window if some other application has already captured the
> mouse. You will have to get a little more fancy if you want to get
> around that problem.
>
> Norm

Yes, it's a problem with entering window, because:
1. It could be other window that captured mouse input.
2. There could be child windows (like scroll bar and so one), that
parent window never received WM_MOUSEMOVE, WM_xBUTTONDOWN messages
from if you don't specified other special message routing for
that child window.
3. It's possible that other windows /or applications used
SendMessage(WM_xBUTTONDOWN/or other... for some reasons.

To be 100% sure in capturing entering mouse to the window the best
way is using SetWindowsHookEx for WH_GETMESSAGE :

hHookNext = SetWindowsHookEx(WH_GETMESSAGE,
(HOOKPROC)GetProcAddress(hHookModule , _T("HookProc")),
AfxGetInstanceHandle(), 0);

But it's some troubles there:
1. It's better to write DLL that contain HOOKPROC for SetWindowsHookEx
(if you supposed to do it in application, than you have to distinguish
between call to HOOKPROC from your application and all the others to avoid
GPF when you are accessing some of your application data from that
HOOKPROC.
In Win16 it was easy by comparing SS and DS and if they are different then
just call CallNextHookEx(...), but I never look on that problem for Win32).

2. It should be some kind of registration of window for that HOOKPROC

3. It's a good idea to copy MSG from *lParam in HOOKPROC to local
buffer before call to CallNextHookEx.

4. It's better to invoke CallNextHookEx before you will be analyzing
incoming message.

5. If MSG contain one of the mouse input message use (but not WM_NCXXX)
CPoint point((DWORD) Msg.lParam);
::ClientToScreen(Msg.hwnd,&point);
hWndBelow = ::WindowFromPoint(point);
if it any of WM_NCXXX mouse input, then you already have Msg.lParam in
screen coordinates.

6. Analyze if it's any registered window or it's child window;
7. If so, then you get mouse entered and you have to set some Entered
status for your HOOKPROC and (possibly) for correspondent WindowProc.

To determine exiting mouse from window is a more trivial task.

Valery Pryamikov

Roger Onslow

unread,

Sep 24, 1996, 3:00:00 AM9/24/96

to

See recent WDJ (Windows Developers Journal) which has an article explaining
exactly how to do this (there are several methods, each of which has
different limitations and benifits).

look in http://www.wdj.com and find sept 96 issue source code.. look for
Zolman.zip in the source code for that month.
The code provided is raw Win32 API (not MFC) but should be easily
adapted/ported to MFC.

Nikhil Kothari <nkot...@ics.uci.edu> wrote in article
<01bba8f7$5566a780$21f4...@uci.edu.uci.edu>...
> Hi,
>
> I would like to do some processing whenever
> the mouse enters into my window and whenever it
> leaves it. (Not just when the window recieves a mouse
> click, but whenever it wanders over the window on the
> screen).
>

Matt Arnold

unread,

Sep 25, 1996, 3:00:00 AM9/25/96

to

"Rainer Strassner" <CTST...@AOL.COM> writes:

>Nikhil Kothari <nkot...@ics.uci.edu> wrote in article
><01bba8f7$5566a780$21f4...@uci.edu.uci.edu>...
>> Hi,
>>
>> I would like to do some processing whenever
>> the mouse enters into my window and whenever it
>> leaves it. (Not just when the window recieves a mouse
>> click, but whenever it wanders over the window on the
>> screen).
>>

>First you have to capture the mouse in this window. Then catch the

>WM_NCMOUSEMOVE - Message. If it comes up first the mouse is leaving the
>window.
>With the first WM_MOUSEMOVE the mouse enters the window again.

Not true.

First, this only happens if you move the mouse *very* slowy. If the
user moves the mouse fast enough, it may skip the window border and
you will not receive any non-client area mouse messages. For a very
small window (like a button), you can even skip over the whole window
and no mouse messages will be received by it at all.

Second, if your window doesn't have a border, you won't receive any
non-client area mouse messages in any case!

Looking for a change between the stream of non-client area and client
area mouse messages is *not* a reliable way to check for the mouse
entering and leaving a window. As others following this trhead have
plready posted, the most reliable methods are ones that involve the
mouse capture and system hooks.

Regards,
-------------------------------------------------------------------------
Matt Arnold | | ||| | |||| | | | || ||
mar...@netcom.com | | ||| | |||| | | | || ||
Boston, MA | 0 | ||| | |||| | | | || ||
617.389.7384 (h) 617.576.2760 (w) | | ||| | |||| | | | || ||
C++, MIDI, Win32/95 developer | | ||| 4 3 1 0 8 3 || ||
-------------------------------------------------------------------------