We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3550

Summary: No mouse move messages send while over the titlebar and windows edges
Product: SDL Reporter: Matthew <0xc0deface>
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.5   
Hardware: x86_64   
OS: Windows 10   
Attachments: proposed patch
A patch for the bug in SDL_CaptureMouse

Description Matthew 2017-01-09 17:45:22 UTC
Its possible to set SDL_CaptureMouse() so you continue receiving mouse input while the mouse is outside your window. This works however There is then a gap where no messages send, which is when the mouse is hovering the title bar and the window edges.

My use case: To move the camera in a 3d application while the user is holding middle mouse button. RelativeMouseMode is not an option as we need to use the cursor, and the cursor needs to be able to leave the window.


SDL_CaptureMouse() would be a good work around if it didn't have this gap in its function.
Comment 1 Matthew 2017-01-26 19:36:19 UTC
Created attachment 2686 [details]
proposed patch

This patch fixes two issues.

1. With SDL_CaptureMouse set, mouse movements while the cursor is over the title bar and window edges would not get sent.
2. With SDL_CaptureMouse set, once the mouse hit the edge of the desktop no further relative movements were registered.

The first is indeed a bug. If this line in SDL_windowsevents.c is to blame:

if (WindowFromPoint(pt) != hwnd) {  /* if in the window, WM_MOUSEMOVE, etc, will cover it. */

The problem is that WM_MOUSEMOVE messages don’t fire when over the non-client area part of a window, therefore there was a gap between the client area and the rest of the desktop where no messages sent.

The path also includes an new feature of a hybrid relative mode, to allow relative mouse movements to be received without having to enable full relative mode which leaves you cursorless.
Comment 2 Matthew 2017-01-26 19:39:04 UTC
Comment on attachment 2686 [details]
proposed patch


The patch can be applied to the latest default which currently is Rev 10854 or hash ca523d8f1af2a197289c330833a8c602bf1c55a9
Comment 3 Sam Lantinga 2017-01-28 05:27:53 UTC
The intent of SDL_CaptureMouse() is that you get mouse events always, even if the mouse is outside the client area of the window.

Can you just fix that without adding a new (and hard to understand) mouse mode?
Comment 4 Matthew 2017-01-28 12:41:52 UTC
Sure! I'll separate the patch into its two parts and upload them here.

Sorry you found the new mouse mode hard to understand. I'm guessing you dont see the need for it? I'll give you a brief explanation of my use case.

My use case is a 3D tool designed to work alongside other tools and apps. For this reason relative mouse mode is out of the question, as the cursor disappears and the mouse is locked to the window until you alt tab or close the window. To move the camera around you click and drag with the various mouse buttons. To continue getting mouse movements outside the window, I turn on SDL_CaptureMouse while a mouse button is being held down. This gets most of the way to what we want, however when the mouse hits the edge of the desktop no more relative movement events fire for mouse motion that would take the cursor past the bounds of the desktop, so the camera stops moving. To get around this I need an in-between mode, where I still get relative mouse movements, but leaves the cursor visible and free to mouse outside my client area to to interact with other windows without having to alt tab first.

This is what i was hoping to achieve with the hybrid relative mode. Trying to get the best of both worlds.

I can adjust naming or anything else you suggest for the new mode, or can choose a different way to achieve the same result if you have any suggestions.

Thanks.
Comment 5 Matthew 2017-01-28 12:44:08 UTC
Created attachment 2690 [details]
A patch for the bug in SDL_CaptureMouse
Comment 6 Sam Lantinga 2017-01-28 19:18:31 UTC
Thanks! Your patch fixes the bug as described:
https://hg.libsdl.org/SDL/rev/2528e46931bd

Can you enter another bug for the issue of the desktop edges?
FYI, I'm completely fine with continuing to get relative motion when hitting the edges of the screen when the mouse is captured.
Comment 7 Matthew 2017-01-30 12:01:39 UTC
Great, Thanks!

The new issue for the desktop edges is here: https://bugzilla.libsdl.org/show_bug.cgi?id=3573

I took your advice and changed the patch so there is no new mode and it simple changes how SDL_CaptureMouse works on windows, to always report relative movements.