Mouse becomes uncaptured when window partly off-screen

[mark_k]

I noticed this issue on Windows 10 1703, so it may well be a bug in that rather than WinUAE.

Start emulation. Drag the emulation window so it's partly off the edge of the screen. E.g. to the right and down so the lower right of the emulation window is off-screen. Click in the emulation window to capture the mouse. If you move your mouse around, eventually it becomes un-captured.

Edit: It happens on Windows 10 1511 build 10586.873 too.

Edit 2: Happens on Windows 7 SP1 32-bit also. There, I moved the emulation window right and down so only the upper-left quarter was still visible. With the mouse captured, moving the mouse around for a while I noticed the Windows mouse pointer appear over the taskbar below the visible part of the emulation window. I could move the Windows mouse pointer left and right, but when it was parallel with the emulation window left edge it wouldn't move any further left. However, right-clicking then seemed to fully un-capture the mouse, after which I could move it anywhere on the Windows desktop.

Edit 3: Also, when the emulation window is partly off-screen, if you move the mouse around, the movement of the Amiga mouse pointer can become constrained to a smaller region of the emulation window (e.g. you can't move it any further right, even though it's only part-way across the Workbench screen).

[Toni Wilen]

I guess these only happen if "windows mouse" is selected?

At least 3 only happens in this mode because Windows completely stops sending WM_MOUSEMOVE reports if mouse is at the edge of screen, even if mouse is still moving towards the edge (Of course out of bounds absolute coordinates would not make sense but also relative movements can't be received..). Windows' mouse pointer is still there but hidden and it is not (and can't be) at the same position as Amiga mouse, if Windows pointer is already at the edge -> hidden border happens.. There is no fix or workaround. (Except to not use "Windows mouse")

[mark_k]

I tried disabling Windows Mouse, instead using "Microsoft USB Wheel Mouse Optical" (raw input?) but that didn't solve the issue. The config I tested with is attached. Is Windows Mouse maybe somehow still enabled in it?

[Tomislav]

You changed mouse in "Game Ports" or "Input". For default settings just change mouse in "Game Ports". If you want use custom settings in "Input" you need to put in "Game Ports" to "<none>" for port which you want to use in "Input" and then modify it in "Input".

[mark_k]

I'm pretty sure WinUAE is using raw input for the mouse, because the Amiga mouse pointer is unaccelerated. Whereas with Windows Mouse, Windows' mouse acceleration also applies to the Amiga side.

When WinUAE "warps" the Windows mouse pointer to the centre of the emulation window, does it warp to the centre of the window, or the centre of the visible region of the Amiga display? If only the upper left quarter of the window is on-screen, I think the cursor should be warped to the centre of the visible part, not the centre of the whole window.

Another possibility/question. When the window is partly off the right & bottom of the screen, does the region which WinUAE clips the mouse cursor to (using ClipCursor() I guess?) specifically exclude the taskbar area? If not, that could explain some cases of the mouse becoming uncaptured.

[mark_k]

I went spelunking through MSDN...

This is updatemouseclip() in win32.cpp (shortened for brevity):

void updatemouseclip (void)
{
    if (showcursor) {
        ClipCursor(NULL);
        amigawinclip_rect = amigawin_rect;
        if (0 && !isfullscreen()) {
            RECT cliprect;
            GetClipCursor(&cliprect);
            IntersectRect(&amigawinclip_rect, &cliprect, &amigawin_rect);
        }
        if (!ClipCursor (&amigawinclip_rect))
            write_log(_T("ClipCursor error %d\n"), GetLastError());
    }
}

So you're clipping the cursor to the intersection of the full screen (ClipCursor(NULL) then GetClipCursor(&cliprect)) with amigawin_rect. But when the window is partly off the bottom of the screen, that rect covers part of the taskbar. Instead I think you should get the work area rect, and intersect that with amigawin_rect.

To find the work area...

The GetSystemMetrics doc says:
"To get the coordinates of the portion of the screen that is not obscured by the system taskbar or by application desktop toolbars, call the SystemParametersInfo function with the SPI_GETWORKAREA value."

The SystemParametersInfo doc says:
"SPI_GETWORKAREA
Retrieves the size of the work area on the primary display monitor. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. [...]
To get the work area of a monitor other than the primary display monitor, call the GetMonitorInfo function."

So if the emulation window isn't on the primary display monitor that might not work. The GetMonitorInfo doc says:
"The GetMonitorInfo function retrieves information about a display monitor."

GetMonitorInfo takes as an argument a pointer to a MONITORINFO structure. The rcWork field of that will be filled in with the work area: "A RECT structure that specifies the work area rectangle of the display monitor, expressed in virtual-screen coordinates. Note that if the monitor is not the primary display monitor, some of the rectangle's coordinates may be negative values."


Edit to add: Also, could doing ClipCursor(NULL) before ClipCursor (&amigawinclip_rect) maybe explain some occurrences of the mouse becoming uncaptured? If in between the two calls to ClipCursor(), the mouse is moved outside the emulation window and another window is activated, WinUAE will lose focus (and presumably release the mouse because of that).

[Toni Wilen]

I think you missed the "if (0 &&" = this was either feature that didn't work or was not finished yet. (I don't remember)

[mark_k]

Ah yes. But the point about clipping to a rect which doesn't include the taskbar still applies.

void updatemouseclip (void)
{
    if (showcursor) {
        ClipCursor(NULL);
        amigawinclip_rect = amigawin_rect;
        if (!ClipCursor (&amigawinclip_rect))
            write_log(_T("ClipCursor error %d\n"), GetLastError());
    }
}

amigawinclip_rect will (I assume?) include part of the taskbar when the emulation window is partly off the bottom of the desktop. And what is ClipCursor(NULL) for?


Edit to add: When WinUAE is using raw input (i.e. not Windows Mouse), could you just clip the cursor to a 1-pixel rect and not bother with "warping" it to the centre of the window, since you don't care about WM_MOUSEMOVE then.

[Toni Wilen]

Multimonitor compatible "workrect"/edge of desktop clipping done.

Too small bounding box for mouse clipping caused some side-effects, unfortunately it was far too long time ago... (I think in some situations it caused feedback loop, windows wanted to move the mouse, winuae moved it back, repeat forever... I am not going to do something that requires something like Windows XP testing..)

[nogginthenog]

I wonder if this will improve WinUAE over Remote Desktop? I guess there's only one way to find out!

[mark_k]

Originally Posted by Toni Wilen

I am not going to do something that requires something like Windows XP testing..)

I totally don't mind testing on XP (in a VirtualBox VM at least).

[Toni Wilen]

Originally Posted by nogginthenog

I wonder if this will improve WinUAE over Remote Desktop? I guess there's only one way to find out!

There is nothing that can fix it completely. (Usual relative vs absolute "mouse" difference)

Originally Posted by mark_k

I totally don't mind testing on XP (in a VirtualBox VM at least).

That is not enough. There can be (bad) background utilities or tablet mouse emulations that move the mouse (or even "move" it to same position.. oldnewthing blog mentioned this few times). It can cause ugly side-effects.

Anyway, above update should fix most related side-effects automatically. Only remaining problem is task bar at the "middle" of multimonitor desktop and winuae window crossing it. This needs some more extra logic.

[mark_k]

After some testing with winuae.7z 2017-05-06 13:48 I couldn't get the mouse to uncapture, either using Windows mouse or raw input. Great!

However, if the size/position of the taskbar (and hence the work area) changes, WinUAE doesn't notice that and the mouse can become uncaptured then. For example:

• Start emulation.
• Un-capture mouse, move over the taskbar, right-click and make sure "Lock the taskbar" is not checked.
• Drag the top border of the taskbar upwards to make it thicker.
• Move emulation window so it's partly over the taskbar. Click in it and move mouse around.

The same thing happens if you move the taskbar to be vertical (on the left or right side of the screen).

Another problem is that if you have the taskbar set to auto-hide, WinUAE (at least the test version I mentioned) hangs on starting emulation. [On Windows 10, enable auto-hide by right-clicking taskbar, select Taskbar settings, then set "Automatically hide the taskbar in desktop mode" to On.]

The same hang happens if "Keep the taskbar on top of other windows" is not checked on Windows XP (and Vista too I assume).

Reading the MSDN page about the taskbar...
"The taskbar supports two display options: Auto-Hide and, in Windows Vista and earlier only, Always On Top (the taskbar is always in this mode in Windows 7 and later). To set these options, the user must open the taskbar shortcut menu, click Properties, and select or clear the Auto-hide the taskbar check box or the Keep the taskbar on top of other windows check box. To retrieve the state of these display options, use the ABM_GETSTATE message. If you would like to be notified when the state of these display options changes, process the ABN_STATECHANGE notification message in your window procedure."

So it looks like you could/should query the work area rect on receiving an ABN_STATECHANGE message. (Or maybe just every time the mouse is captured???)

ABM_GETSTATE seems a bit useless with regard to ABS_ALWAYSONTOP, because the doc says "Note As of Windows 7, ABS_ALWAYSONTOP is no longer returned because the taskbar is always in that state. Older code should be updated to ignore the absence of this value in not assume that return value to mean that the taskbar is not in the always-on-top state."

[Toni Wilen]

Added re-enumeration of displays (so that all displays have up to date workrect info) each time mouse is going to get captured.

[mark_k]

Thanks.

WinUAE still hangs after you enable taskbar auto-hide. (Perhaps any time the work area rect = entire display, or taskbar area rect is zero-size???)

It hangs immediately when you next capture the mouse after changing the auto-hide option.

[Toni Wilen]

Fixed.

[mark_k]

Aaargh. You'd think Microsoft would provide an easy way to reliably capture the mouse, wouldn't you?!?!

There's a problem when taskbar is set to auto-hide (at least on Windows 10 1703). When the taskbar is set to auto-hide, it reappears when the user moves the mouse to the very bottom of the screen.

With "Activate a window by hovering over it with the mouse" disabled (which is the default), with emulation window partly off the bottom of the desktop, the taskbar can reappear with the Windows mouse pointer over it, underneath the visible part of the emulation window. Right-clicking then fully uncaptures it.

With "Activate a window by hovering over it with the mouse" enabled, the mouse can become fully uncaptured without needing to right-click it.


My guess: when the taskbar is set to auto-hide (and is hidden), the work area rect is returned as the entire screen. So WinUAE clips the mouse to the work area, but that allows the Windows cursor to reach the very bottom of the screen, causing the taskbar to reappear. When it reappears WinUAE doesn't get the new work area (which may or may not still be the whole screen???) and change the mouse clip rect.

If re-enumerating displays on ABN_STATECHANGE isn't sufficient (e.g. maybe Windows doesn't send ABN_STATECHANGE when the taskbar appears/hides, but only when the user changes the auto-hide setting???), then you might have to mess with ABM_GETAUTOHIDEBAREX to find out which of the screen edges have auto-hiding toolbars, and restrict the mouse clip rect to not include those screen edges. Or could just never including any screen edges in the mouse clip rect be good enough?

[Toni Wilen]

Right, fixing returned workrect to always include hidden "app bars" is probably the best solution. Done.

btw, SHAppBarMessage(ABM_GETAUTOHIDEBAREX) is really ugly API. It requires number of monitors times 4 (each edge) to get all possible hidden "app bars". Design is quite annoying.. Apparently it is Vista+ only (For some reason MSDN does not mention required OS version)

[mark_k]

The (non-EX) ABM_GETAUTOHIDEBAR doc says it's supported on XP. But that only applies to the primary monitor: "Retrieves the handle to the autohide appbar associated with an edge of the screen. If the system has multiple monitors, the monitor that contains the primary taskbar is used."

[Toni Wilen]

Yes but non-EX version is useless. Multimonitor support is required.