Movement Threshold

[33XAnt]

A customizable (pixel #) distance threshold for the actions that require mouse movement, such as 'change movement to scroll', 'slow down mouse cursor (while pressed)', and 'lock mouse axis (while pressed)', would be a real benefit to ease of use.

It would also make a great difference in how both button 'held' and 'chording' perform with the options abort/unblock on mouse move used. So that small movements don't inadvertently cancel a user's intentions.

TIA

[phil]

Change movement to scroll is not initiated by move movement, it is initiated by the button press. There is a sensitivity but that controls how reactive it is to movement.

The abort chording on movement is now configurable (in the latest beta), I expect that will extend to the abort button held (but not yet, still verifying that it works for chording as expected - its a recent addition) but I can't see how that possibly relate to the change movement to scroll/axis locking?!

[33XAnt]

Once again, you're already ahead of the game. I'll install the latest beta to see how it cleans up the chording behavior.

but I can't see how that possibly relate to the change movement to scroll/axis locking?!

My thought was that a buffer of a few pixels would give more meticulous precision before inadvertently starting such actions. But, I omitted the use case of having a button already assigned to an another function; which would already be taken care of by either holding or chording. So it's already included in your development pipeline. Can't wait to try it out.
  Truly appreciate the work you've done.

[phil]

The beta is already available so feel free to try it. It seems the movement in button held is not yet configurable though in the GUI at least so I will have to add that in before release

[33XAnt]

The pixel buffer – for button chording – performs very well! The unintentional discarding of chorded activities is now mitigated easily. I'm sure the effect will be the same when the 'button held' actions get this same tweak.

I am still experiencing a hiccup with the main mouse button, though; assigning button chording causes it to remain in a held down (sticky) state, when dragging elements (scrollbars, file icons, etc.) around in explorer and some other applications; which means a second click is required to release an element that's been dragged. My left button doesn't have a secondary assignment under chording, it's set to the default (unchanged) function. I assume this (dragging the mouse with chording) would have this effect on other mouse buttons, but they aren't typically used to do hold–then–drag actions within Windows, so haven't tested a use case where this would occur. At times, a second regular click is required to get the standard left click to take effect (even without dragging an element), so this might not be exclusive to dragging things (though, that's how I most frequently experience this miscue). Sometimes holding the button for the assigned milliseconds value will avoid these issues, but not in every scenario; and the pixel threshold (even at 0) doesn't resolve the problem. When 'block/delay original action' is completely turned off this behavior disappears altogether.

Thanks

[phil]

Ive noticed this too on the right button which I use for cording... But Ive never been able to understand why it sometimes gets stuck down, and in the beta I spent a lot of time looking at it, to no avail... I don't know if its a timing thing, or something I have missed but I'm still investigation, but unsure if I will ever find a 100% working solution!

When not blocking the original, XMBC does not get involved and intercept/relay/simulate the original so that's why that's OK. Its as if XMBC is failing to send the final button up, but I don't think that is the case - at least, its sending it, I wonder if the thread for the send queue is getting aborted/flushed or something - more ideas to look at!

It would be easier to debug if it happened *every time* but its seemingly random (at least for me)!

[33XAnt]

The way I encountered/noticed chorded button sticking is through a method that's 100% reproducible, at least on my system:
I use a software called EZ CD Audio Converter {available from www.poikosoft.com}, in which I frequently drag explorer folders onto the interface to load their contents (audio files) into the application. With the left mouse set to chording on the default profile, every time this action is performed, the dragged contents stay stuck in limbo until another left click is made.
Dragging the scrollbars in this application also makes the issue arise just about every time.

It's not a free application; so if you require the results from my series of actions, to confirm what's going on - I'll provide that through your app's debug logging.

Also note that my device is a Surface tablet, which could possibly differ from regular laptops, etc.

[phil]

The debug log may be useful, particularly along with the rough timestamps the problem happens.
It would be good if we can find a common (free) application that suffers too - does it happen when dragging to Explorer?
I the chording setup on the default profile or an app specific profile (I wonder if the profile switching may be the problem).

I have 3 surface pro's here of varying ages (2, 7, 9) so that shouldn't be a problem - I presume your using a mouse or the touchpad rather than touchscreen at this point?!

[33XAnt]

Most of the info about my setup is in my signature , I'll include additional info if needed.

With the left mouse set to chording on the default profile, every time this action is performed...

I did put that problematic chording setup through its paces with some other apps:

1. Confined within an Explorer folder itself, it does occur quite frequently ( = 50% ) when just clicking a blank area within a folder or dragging the upper (no-longer-possessing-a-title) bar.
2. With the Winamp (WACUP) media player sticking didn't occur. This app doesn't use a standard Windows GUI.

 
Since it behaves badly in Explorer all on its lonesome you don't likely need to hunt for any particular apps
I'll do some more specific troubleshooting, to exclude some things, then get back to you with that log file.

[33XAnt]

Sorry for the delay in getting this data to you. After several restarts it was much less consistent/predictable. I'll be more on top of this in the future, at whatever pace you need/can move with the evaluation. I don't presume any rush towards a solution.

XMouseButtonControl.log

[33XAnt]

I know it was mentioned by you before; so it may be useful to know that toggling (enable & disable) the profile for the program - EZ CD Audio Converter - I mentioned prior, does make a major impact on how frequently the sticking occurs with left button chording. I'm only discussing that app because using it is the most reliable (practically 100% of the time) way to get the sticking to happen. It does occur frequently enough in Explorer folders all by themselves, that I hope you can narrow it down without the application I'm using.
Also, I have my complete XMouse profile saved, and would like to share it (if that would be at all useful?). But it's too big a file for the forum to accept it.

[phil]

Sure it would be handy to have a copy of the profile - I don't believe the forum has a size limit but maybe I'm wrong, just zip it up (its text so it should zip very well) and PM it to me.

I'm sorry that i haven't had a chance to look into this yet - this time of year, my weekends are quite busy and work has been nightmare busy recently! Not sure when I will get a spare moment but rest assured, it is on the list of things to try and figure out (I have been trying for some time so I'm not 100% confident I will find it, but the more examples of it going wrong the better - it happens to be occasionally, always at the worst possible time to try and actually debug it (because its usually when I'm busy at work lol)!