swiftcoder's picture

Mouse up outside window doesn't register

Project:The Open Toolkit library
Version:1.1.0-stable
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed
Description

This is likely a symptom of one of the previous support tickets, but I didn't find anything that quite described the issue, so here goes nothing...

When the user clicks the mouse within the window, drags to a point outside the window, and then releases the mouse, no MouseUp event will be delivered, and the MouseDevice will firmly believe that the mouse button is still down.

Perhaps needless to say, this makes any kind of mouse-driven camera manipulation extremely unpleasant/unworkable. Equally, while the in-progress mouse capture functionality will allow one to work around this bug, I think it is still a bug: most standard Windows controls (i.e. buttons) respond to MouseUp events outside of their frame.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Version:all versions» 1.0-2010-10-06
Status:open» in progress

Fixed on Windows in trunk r2916.

the Fiddler's picture

#2

Confirmed to work correctly on Linux.

swiftcoder's picture

#3

My apologies if you already corrected this as well, but I haven't had time to compile trunk and test it.

It seems that mouse move events are also not provided when the cursor is outside of the window. This isn't a big problem in general, but again it cause problems with tracking mouse dragging.

the Fiddler's picture

#4

This is by design: both Windows and Linux stop sending MouseMove events once the pointer leaves the window. OpenTK trunk implements a complementary input system that covers such scenarios:

var mouse = MouseState.GetState();
var delta_x = mouse.X - mouse_old.X;
var delta_y = mouse.Y - mouse_old.Y;
mouse_old = mouse;

This works regardless of input focus.

zeno's picture

#5

Priority:normal» critical

This still haven't been fixed even in the latest version. Mouse up events are not fired properly. I consider this a critical bug.

Once the mouse button goes down in the GameWindow, mouse up event should always be fired regardless of where the mouse up event happens.
This is how it works for WinForms.
Any other way than this is a huge inconsistency and an incorrect implementation.

Please fix this.

Artfunkel's picture

#6

I fixed this bug on Windows for my project. It's very simple: when a mousedown event is detected call SetCapture(), and when a mouseup event is detected call ReleaseCapture().

No idea about other platforms. I'd upload a patch but my computer died the other day!

Edit: for clarity, this prompts Windows to keep posting mouse input events to your program if the pointer leaves the OpenTK window. It doesn't prevent the pointer from leaving the window as the word "capture" might imply.

Artfunkel's picture

#7

Patching against SVN latest was a little more involved: http://pastebin.com/HzYbJDV7

AndyKorth's picture

#8

Thanks Artfunkel.

I have commit this patch to: https://github.com/andykorth/opentk/

Additionally, I've added a way to test for this behavior to the BasicMouseInput example. While I haven't been able to test your patch on a windows machine, these test should make it easy. (if you use the example browser program, it's the first test under OpenTK.)

In the current Mac code, mouseups always occur, even if the cursor is outside of the OpenTK window.At least the behavior is now the same for Mac and Windows. I think what Fiddler meant by "Confirmed to work correctly on Linux." is that it behaves this way as well.

Commit for the fix is: https://github.com/andykorth/opentk/commit/5b0db16a89b9648d04627ae60e902...

AndyKorth's picture

#9

Status:in progress» in progress (review)

Thanks Artfunkel.

I have commit this patch to: https://github.com/andykorth/opentk/

Additionally, I've added a way to test for this behavior to the BasicMouseInput example. While I haven't been able to test your patch on a windows machine, these test should make it easy. (if you use the example browser program, it's the first test under OpenTK.)

In the current Mac code, mouseups always occur, even if the cursor is outside of the OpenTK window.At least the behavior is now the same for Mac and Windows. I think what Fiddler meant by "Confirmed to work correctly on Linux." is that it behaves this way as well.

Commit for the fix is: https://github.com/andykorth/opentk/commit/5b0db16a89b9648d04627ae60e902...

the Fiddler's picture

#10

Version:1.0-2010-10-06» 1.1.0-stable
Status:in progress (review)» closed

This fix is included in opentk-1.1.0. Thanks AndyKorth!