Goes into bad state and freezes entirely after pressing scroll buttons without scroll

[calzadilla]

Hi Martin,

Thank you for this program and the source... it is pretty awesome!

I use Logitech's Trackman Marble and Windows 10. The program worked flawlessly the first day with a bit of a lag when going forward and back in browser. After using a combination of forward and back several times with scrolling the program completely freezes up and ceases to function. I was not even able to kill it through task manager, so I restarted my computer to get it going again. I am able to repeat this again and again.

[calzadilla]

When going into the code I noticed NativeMethods.SendInput() was my problem. I removed the code that builds up the input array and the call to NativeMethods.SendInput() and I am now setting the preventCallNextHookEx flag to false inside this same IF block. This has made everything work fast and not freeze up. If you want I can send you a pull request.

[Seelge]

Thank you for the issue, I encountered this bug but very rarely (read: twice) and could never reproduce it successfully. Does it only happen when pressing both the forward and backward-button simultaneously?

Unfortunately removing the SendInput call would remove a basic functionality of the tool and it seems to work in most cases. But I can add another option to disable the middle clicking function.

[calzadilla]

What is interesting for me is that both my buttons go into that block. Your comment says "DOWN->NORMAL: middle button click" but for me it is both (I don't have a middle button).

I did not need to call SendInput() explicitly as long as I set preventCallNextHookEx to false my normal button behavior fires.

To reproduce the problem I did not have to press both buttons at the same time, just one or the other.

I believe what is happening in my case is that the SendInput() is very slow and the calls pile up to the point where it becomes unresponsive.

Even when it works I experienced the lag I told you about when wanting my normal button behavior because of the delay of SendInput().

I did not lose any functionality, in my case, it just made the program significantly faster when switching between normal button behavior and scrolling. If I left "preventCallNextHookEx" set to true then my normal button behavior does not fire.

Here is the code I am using with no loss of functionality:

if (WinAPI.MouseMessages.WM_XBUTTONUP == (WinAPI.MouseMessages)wParam) { // DOWN->NORMAL: middle button click if (!(useX1 && xbutton == 1) && !(useX2 && xbutton == 2)) { break; }

preventCallNextHookEx = false;
_state = State.NORMAL;

//WinAPI.INPUT[] input = new WinAPI.INPUT[2];
//input[0].type = WinAPI.INPUT_MOUSE;
//input[0].mi.dx = p.pt.x;
//input[0].mi.dy = p.pt.y;
//input[0].mi.mouseData = 0x0;
//input[0].mi.dwFlags = (uint)WinAPI.MouseEvent.MOUSEEVENTF_MIDDLEDOWN; // middle button down
//input[0].mi.time = 0x0;
//input[0].mi.dwExtraInfo = IntPtr.Zero;
//input[1].type = WinAPI.INPUT_MOUSE;
//input[1].mi.dx = p.pt.x;
//input[1].mi.dy = p.pt.y;
//input[1].mi.mouseData = 0x0;
//input[1].mi.dwFlags = (uint)WinAPI.MouseEvent.MOUSEEVENTF_MIDDLEUP; // middle button up
//input[1].mi.time = 0x0;
//input[1].mi.dwExtraInfo = IntPtr.Zero;
//NativeMethods.SendInput((uint)input.Length, input, Marshal.SizeOf(typeof(WinAPI.INPUT)));

} else if (WinAPI.MouseMessages.WM_MOUSEMOVE == (WinAPI.MouseMessages)wParam) { // DOWN->SCROLL preventCallNextHookEx = true; _state = State.SCROLL; _xcount = 0; _ycount = 0; System.Windows.Forms.Cursor.Position = _originScaled; } break;

[Seelge]

with no loss of functionality

Your code disables emitting middle button clicks using the X-buttons.

The section below the comment DOWN->NORMAL: middle button click triggers when one of the X-buttons is released without moving the trackball. In those cases a middle click event (middle button down+up) is emitted.

I have added a button to the tray menu in v4 which disables the problematic middle click functionality.

Since v4 is only a work around I'll keep the issue open.

[calzadilla]

Awesome. I see what you mean. "No loss of functionality" is in my case since I have no need to use middle button clicks. Thank you for taking the time and looking into it!

[Seelge]

Memo: https://stackoverflow.com/questions/42236886/sending-scroll-commands-with-sendinput-on-windows10-uwp-applications

This is not a uwp app but the freezing sounds familiar to this and #14.

[mentalisttraceur]

I just had to switch my work computer to Windows 10 and while I'm not exactly sure what sequence of too-quick-for-me-to-consciously-notice clicks or movements I sometimes accidentally do to trigger this, it makes this program basically unusable for me now.

I can reliably bet that sometime between booting up my computer and a couple days later (right now before making this post it was literally within an hour of starting from a fresh boot), I will accidentally make some movement or click that triggers this bug.

And the fact that the program simply won't die no matter how I try to kill it, and that starting a new one doesn't work either means I either have to stop what I'm doing and fully restart, or just not scroll with the mouse (inevitably I do it anyway out of habit and muscle memory and mess up my web browser state), or just unplug the mouse and revert to a normal mouse with all the disadvantages of that for my usage patterns.

While I appreciate that loss of middle mouse click functionality matters, for me as a user the difference of this suggested change is between "reliable base functionality" and "probabilistically no functionality".

Maybe add a setting that's off by default to flip the code to this suggested change until we are able to figure out why this happens and fix it?

[Seelge]

Thank you for your feedback. I agree that this is a major issue, especially in a production environment.

The option to disable the middle mouse click functionality already exists in the right click menu of the software tray icon and it remembers it's setting so you only need to deactivate it once.