New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send MouseButtonReleased events when the mouse is outside the window on Windows #455

Closed
Wizzard033 opened this Issue Aug 26, 2013 · 9 comments

Comments

Projects
None yet
5 participants
@Wizzard033

Wizzard033 commented Aug 26, 2013

I was attempting to request a feature from TGUI, the SFML GUI, here in this thread http://forum.tgui.eu/index.php?topic=123

However, Texus, developer of TGUI, says that the feature I requested already exists on Linux and only does not work on Windows because of an inconsistency in SFML.
The problem is that MouseButtonReleased events are not sent to properly close out a MouseButtonPressed event when the mouse is dragged outside the window.
Texus says in that thread that in Linux MouseButtonReleased events are sent correctly in this case.

Put simply, if one is to click and hold the left mouse button inside a SFML window on Windows, then move the mouse outside of the SFML window and stop holding the left mouse button down, only a MouseButtonPressed event happened.
This is supposedly inconsistent with Linux and is definitely inconsistent with what I think should happen.

@ghost ghost assigned LaurentGomila Aug 26, 2013

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 26, 2013

Member

Tough question... because what you're describing is the default behavior for Windows (you won't get a mouse up event if the cursor isn't over your window). And yes, this can have a rather weird "sticky" behavior if you try to use drag & drop in some games.

Member

MarioLiebisch commented Aug 26, 2013

Tough question... because what you're describing is the default behavior for Windows (you won't get a mouse up event if the cursor isn't over your window). And yes, this can have a rather weird "sticky" behavior if you try to use drag & drop in some games.

@Wizzard033

This comment has been minimized.

Show comment
Hide comment
@Wizzard033

Wizzard033 Aug 29, 2013

Is this fixed in your patch or is it being waited on to see if this is desired behavior?

Wizzard033 commented Aug 29, 2013

Is this fixed in your patch or is it being waited on to see if this is desired behavior?

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 29, 2013

Member

My latest implementation fixes this, i.e. you'll get a mouse up event even outside the window. I've did some testing and it's - unfortunately - not really constant between games and applications. Some will ignore the activating click, others will react to it. Doing it this way (i.e. not dropping it) allows the user to determine whether they'd like to take the first click.

Member

MarioLiebisch commented Aug 29, 2013

My latest implementation fixes this, i.e. you'll get a mouse up event even outside the window. I've did some testing and it's - unfortunately - not really constant between games and applications. Some will ignore the activating click, others will react to it. Doing it this way (i.e. not dropping it) allows the user to determine whether they'd like to take the first click.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Aug 29, 2013

Member

And what about the initial problem, which led to the broken implementation? The problem was that if you hold a mouse button and really quickly leave the window, the MouseLeft event will sometimes not be triggered (if I remember correctly). So is it still fixed with your code?

Member

LaurentGomila commented Aug 29, 2013

And what about the initial problem, which led to the broken implementation? The problem was that if you hold a mouse button and really quickly leave the window, the MouseLeft event will sometimes not be triggered (if I remember correctly). So is it still fixed with your code?

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 29, 2013

Member

At least I couldn't reproduce it. Plus the code around the mouse capture should handle that either case (you'll still get mouse movement outside the window, no matter how far or how fast you move the cursor; so the event wil trigger, even if it's not caught by WM_MOUSELEAVE).

Member

MarioLiebisch commented Aug 29, 2013

At least I couldn't reproduce it. Plus the code around the mouse capture should handle that either case (you'll still get mouse movement outside the window, no matter how far or how fast you move the cursor; so the event wil trigger, even if it's not caught by WM_MOUSELEAVE).

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Sep 25, 2013

Member

Fixed by #457

Member

LaurentGomila commented Sep 25, 2013

Fixed by #457

LaurentGomila added a commit that referenced this issue Sep 25, 2013

Merge pull request #457 from MarioLiebisch/issue-437
Fixed mouse clicks not activating windows (Win32) (#437, #455)
@miki151

This comment has been minimized.

Show comment
Hide comment
@miki151

miki151 Feb 7, 2014

Is there a workaround that I can put in my code so this doesn't happen with SFML 2.1 on Windows? I mean the issue where the mouse button is released outside the window, and the program doesn't register the event. Thanks.

miki151 commented Feb 7, 2014

Is there a workaround that I can put in my code so this doesn't happen with SFML 2.1 on Windows? I mean the issue where the mouse button is released outside the window, and the program doesn't register the event. Thanks.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Feb 8, 2014

Member

Just compile SFML from source, it's really useless trying to get workarounds if it's already fixed, just to avoid build from source.

Member

eXpl0it3r commented Feb 8, 2014

Just compile SFML from source, it's really useless trying to get workarounds if it's already fixed, just to avoid build from source.

@miki151

This comment has been minimized.

Show comment
Hide comment
@miki151

miki151 Feb 8, 2014

Yeah and then everyone who wants to compile my code has to compile SFML
himself too.

I worked around the problem (I think) by reading the mouse state directly
from the Mouse class.

On Sat, Feb 8, 2014 at 10:06 AM, Lukas Dürrenberger <
notifications@github.com> wrote:

Just compile SFML from source, it's really useless trying to get
workarounds if it's already fixed, just to avoid build from source.

Reply to this email directly or view it on GitHubhttps://github.com//issues/455#issuecomment-34539190
.

miki151 commented Feb 8, 2014

Yeah and then everyone who wants to compile my code has to compile SFML
himself too.

I worked around the problem (I think) by reading the mouse state directly
from the Mouse class.

On Sat, Feb 8, 2014 at 10:06 AM, Lukas Dürrenberger <
notifications@github.com> wrote:

Just compile SFML from source, it's really useless trying to get
workarounds if it's already fixed, just to avoid build from source.

Reply to this email directly or view it on GitHubhttps://github.com//issues/455#issuecomment-34539190
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment