I'll try to explain a few things. Because some misconceptions have cropped up and stuff Matty posted didn't work because of certain things and the 'fixes' for them weren't the proper fixes, and they introduced other misconceptions...
A window has a client area and a non-client area.
The non-client area of a standard window in Windows is the title/caption bar (plus the borders).
Clicking and holding the button in the caption area of the non-client area of a window and you can move the window for example.
Plus!, by default, flags the whole window as the non-client area, making it possible to click anywhere to move the window (can be disabled by setting LockOnClick to false).
WM_MOUSEMOVE (and other notifications like this), only work in the client area. For the non-client area you need to use other notifications! eg: WM_NCMOUSEMOVE
In short, instead of setting LockOnClick to false, use WM_NC
So, refering back to this post
from Matty: it wouldn't work because:
MOUSEMOVE should have been used when LockOnClick is true (default).
b) the syntax of the ChildWindowFromPoint is wrong. The POINT structure must be passed literally, not as an object reference. See attached script for correct syntax.
c) ChildWindowFromPoint expects coordinates in client coordinates. Matty forgot to convert the screen coordinates from the cursor into client coordinates.
d) see (2)
of Matty (setting LockOnClick to false) would only solve point a.
If the four points above would have been correct, that little script would have worked correctly, except for the fact that:
Since a button control is a window on its own, you wont get any notifications when you move (or hoover) over the button control though.
You need to subclass that button control instead to get a MOUSEMOUVE notification when you move over that control. But this not possible in Plus! without an external DLL
Note that detecting WM_NOTIFY, WM_PRINTCLIENT and WM_CTLCOLORBTN messages, send to the parent window, can also be used to detect the mouse entering and leaving a button on the Plus! window. Unfortunalty you can't distinct entering or leaving with these APIs alone.
WM_PRINTCLIENT gives the hDC of the button
WM_NOTIFY gives the control/window id
WM_CTLCOLORBTN gives the hDC and hWnd of the button (use this one as the hWnd is the most easiest to check on)
However, this isn't detecting hovering though. But it might be a solution depending on what you exactly want.
If all else fails, you could use a timer and check the mouse coordinates if they are in the button's view port coordinates and if the parent window is in the foreground. If so, you are over the button. Another timer can then be used to detect the 'hovering'.
Of course, using (4) requires constant polling and we all know how we hate that ;p
But you can combine the advantages of (3)(check on WM_CTLCOLORBTN)
and (4)(check coordinates)
together so you don't have the disadvantage of pure (4)(constant polling with timers)
and the problem of (2)(no MOUSEMOVE event when you are on a child control)
When you detect WM_CTLCOLORBTN, check the mouse coordinates against the button's view port and you know if the mouse is over the button or not.
Beware though, with this method, the final event (the debug messages in the example script) is also fired when the window is put in focus and out of focus (eg: <alt><tab>). This shouldn't be a problem in general, but for certain stuff (dunno exactly what you're going to do) it might be troublesome.
See attachment for a crude script using this method. Only the cancel button will generate the "I ENTERED"/"I LEFT" debug messages, not the Start button, neither the minimize or close button.
PS: In this script I have also included the WM_NCMOUSEMOVE notification, and the MOUSETRACK events to show how they work. You don't need those for this method to work though....
Hopefully this long jabber isn't too confusing or too messy. And hopefully you'll eventually find a solution for what you want to do... :p