Shoutbox

Add this. All will be good

xml code:

---

        <Attributes>
            <LockOnClick>False</LockOnClick>
        </Attributes>

---

But.. That disables moving the window, right? And besides, I get tons of notification messages with the LockOnClick thingy, except when the mouse is over a control.

quote:

---

Originally posted by SmokingCookie
But.. That disables moving the window, right? And besides, I get tons of notification messages with the LockOnClick thingy, except when the mouse is over a control.

---

It will disable moving the window yes. Sorry I wasn't clear in my post. I didn't spend the time trying to figure out what control the cursor was on. I can take a look later if you cannot figure it out.

The other possibility is to create regions for different buttons and monitor the position of the cursor when it is on the window. That is quite intense though.

Regions? Never really heard of that, I think...

The attachment includes an example of what I want to do with this. It's written in MS Visual C# Express 2010.

Good news... bad news...

Good news is I managed to get it to work with the Plus! Window. Unfortunately I can't see how it will work with controls.

js code:

---

var WM_MOUSEMOVE = 0x200;
var WM_MOUSEHOVER = 0x02A1;
var TME_HOVER = 1;
var wndSubclass;

function OnEvent_Initialize() {
    if (Messenger.MyStatus < STATUS_INVISIBLE) return false;
    Debug.DebuggingWindowVisible = true;
    wndSubclass = MsgPlus.CreateWnd('wndSubclass.xml', 'wndSubclass');
    wndSubclass.RegisterMessageNotification(WM_MOUSEMOVE);
    wndSubclass.RegisterMessageNotification(WM_MOUSEHOVER);
}

function OnEvent_SigninReady() {
    OnEvent_Initialize();
}

function OnwndSubclassEvent_MessageNotification(pPlusWnd, nMessage, wParam, lParam) {
    switch (nMessage) {
        case WM_MOUSEMOVE:
            Debug.ClearDebuggingWindow();
            Debug.Trace('WM_MOUSEMOVE');
            var TRACKMOUSEEVENT = Interop.Allocate(16);
            with(TRACKMOUSEEVENT) {
                WriteDWORD(0, Size);
                WriteDWORD(4, TME_HOVER);
                WriteDWORD(8, pPlusWnd.Handle);
                WriteDWORD(12, 1);
            }
            Interop.Call('user32','TrackMouseEvent',TRACKMOUSEEVENT.DataPtr);
            return -1; // Process the message little one
        case WM_MOUSEHOVER:
            Debug.ClearDebuggingWindow();
            Debug.Trace('WM_MOUSEHOVER');
            return -1;
    }
}

---

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...


(1)

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, WM_NCLBUTTONDOWN, etc...

In short, instead of setting LockOnClick to false, use WM_NCMOUSEMOVE.

So, refering back to this post from Matty: it wouldn't work because:
a) WM_NCMOUSEMOVE 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)

this post 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:

(2)

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.

---------

(3)

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.

---------

(4)

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'.

---------

(5)

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

Looks good Cook! Thanks for the explanation. I couldn't seem to come up with a message that was sent to the parent that we could act on.

Not supposed to be online now; at school.

Anyways, cannot download Cookie's attachment, so I'll take a look at it later today, or tomorrow. Meanwhile, what exactly does it do?

Captures mouse enter/leaving of a button.