Stop all mouse movement for a specific amount of time

[doctor953]

Please fill in this template when posting!
XMBC Version: 2.19.2
Installed or Portable version:
Windows Version: Windows 10 Version 21H2
Mouse Information (brand/model): Logitech M330
Relevant Computer Information (CPU, RAM etc): Core i5-8300H, 8GB RAM
Did the problem occur after an upgrade of XMBC? (If so, from what version?): n/a
Did the problem occur after a Windows update/upgrade? (If so, from what version?): n/a
How long have you used XMBC?: a few weeks
What language and keyboard layout do you use in Windows?: English - United States

Clear description of the problem - try and include as much information as possible, including what button and mappings you are having problems with (if applicable).:

Loving X-Mouse Button Control. I think it is a fabulous piece of software. Thank you for writing it.

I wonder if it is possible to press a button on the mouse and have all mouse movement stop or be ignored for a specific amount of time, such as a tenth of a second. The mouse buttons can be clicked and processed, but any movement of the physical mouse won't be represented by movement of the mouse cursor.

Thank you.

[doctor953]

Well, I guess a non-answer, in this case, means no. Well, I appreciate your time. Thank you.

[phil]

No it means I havnt gotten round to replying - I'm afraid I have other things going on in my life too!

But actually, in this case, it is a no - not currently possible! Might be able to change that, but it certainly wont be quick (Ive got a growing list of over 2+ years on the list!)

The only options at the moment are to lock the X and Y axis (you can do that while a button is held, or until the button is pressed again) but no release on a timer facility...

Regards,
Phil

[doctor953]

I apologize for my impatience.

I thought it wasn't possible to lock both the x-axis and y-axis, at the same time.

And maybe I misunderstood, I thought locking the axis meant you could only move in that axis (locking the x-axis would only allow movement in the x-axis but not the y-axis, for example). If you lock both, wouldn't you be allowing all movement (the x-axis lock would allow movement in the x-axis and the y-axis lock would allow movement in the y-axis, both on allows all movement)? Or do I have the understanding opposite to what it actually is (locking the x-axis prevents movement in the x-axis but allows in the y-axis, and locking the y-axis prevents movements in the y-axis but allows movement in the x-axis, locking both would block moving in both)? Or would preventing movement in the other axis and turning them both on, stop movement in both axis (one blocks the other, and the other blocks the one)? I am trying to wrap my head around this.

If I can stop all movement by locking both the x-axis and the y-axis, this could work for me, even without the time component that I asked about.

[phil]

I apologize for my impatience.

No problem, I usually try and get round to replying quicker - but it was a bit of a heavy weekend

I thought it wasn't possible to lock both the x-axis and y-axis, at the same time.

And maybe I misunderstood, I thought locking the axis meant you could only move in that axis (locking the x-axis would only allow movement in the x-axis but not the y-axis, for example). If you lock both, wouldn't you be allowing all movement? Or do I have the understanding opposite to what it actually is? Or would preventing movement in the other axis and turning them both on, stop movement in both axis? I am trying to wrap my head around this.

My interpretation of "locking X" means no movement will be allowed on the X axis (horizontal).
So, if you lock the x-axis, it means the X axis (horizontal) is locked in place, and it will only move on the Y (vertical) axis. I guess if it said "lock to x" it mean how you interpreted it... Isn't English beautifully ambiguous

So anyway, locking both (which you can do from simulated keystrokes tags {LOCKXY}) stops all movement!

If I can stop all movement by locking both the x-axis and the y-axis, this could work for me, even without the time component that I asked about.

Give it a try. Set the button to 'simulated keystrokes', Choose method 3 (during) to start with (so while the button is held down) and use {LOCKXY} in the key input field.

That should lock movement while the button is held down.

Thinking about it, you actually may be able to lock it and unlock after a time too, possibly! I'm not sure this will work or how reliable it will be but you could try...
SimKeys again, Use method 1 or 2, and try {LOCKXY}{WAITMS:1000}{UNLOCKXY}

In theory, that will, as soon as the button is pressed (1) or released (2), block movement for 1second - but it may be problematic. Worst case it could stay locked. You can also setup global hotkeys or layer modifier keys to toggle locking (but not both axis on one key at the moment) - might be useful though to unlock it if it ever gets stuck locked.

NOTE: There is also a 'get out of jail free' card - useful if anything in XMBC stops working (or you map the left/right buttons and "break" normal operation!), just turn on scroll lock to disable XMBC temporarily (which will also unlock any locked axis!) - NOTE This is optional, its on by default but can be turned off in General Settings by un-ticking "Bypass ALL actions when SCROLL LOCK is ON". if you don't have a scroll lock key, you can also setup global hotkey combos to toggle XMBC disabled/enabled.

[doctor953]

Oh wow. I didn't think about using simulated keystrokes. That would make things much easier than I was thinking. I was envisioning doing a series of simulated right clicks to move between multiple layers to lock each axis, doing what I needed, and then unlocking them. A simple use of simulated keystrokes would make it very easy if I can integrate that into what I am doing.

To clue you in on what I am doing, I have a PowerPoint presentation that uses VBA coding for a gameshow that I run online. Things get complicated during the game to the point that to make all the animations run correctly, a series of mouse movements and clicks are done at variable amounts of time. But some of those movements and clicks are done in succession. So, through the VBA, I have it automating those movements and clicks that are one after the other, which makes things simpler for me to run the game because I have less to think about and do. However, if I move the mouse too much while it is trying to do those automated movements and clicks, it can miss a click on an onscreen object, messing up the whole pattern.

I used X-Mouse Button Control to slow the mouse down to a crawl by having PowerPoint VBA send an automated right click at the start of these sequences to slow the mouse movement to setting 1 and then another right click to return to normal speed after the sequence has concluded. That cut down about 90% of the problem that I was having. But, that 10% remained where I was just too fast even with the mouse moving at a snail's pace. If I could absolutely stop all movement during these sequences, that would remove 100% of the problem.

Thank you. I have something to work with!

[doctor953]

Hi. I wanted to give an update to the thread.

To kind of recap, I am writing software in VBA for a gameshow which I run online. In this game, there is a complicated sequence of clicks of the mouse on various transparent onscreen buttons, which I know the location of and the players of the game do not see clicked (because the mouse pointer is on a presenter's view on another monitor that only I see). These transparent buttons start and stop various onscreen "lights", trigger sound effects, and control the flow of a turn. To help me run the game (which is fairly complex already without the complicated sequence of clicks), I have automated a number of these clicks by having various commands in VBA move the mouse and do simulated clicks in a correct sequence. The problem comes in if I inadvertently move the mouse at the wrong time causing the mouse to move off a transparent button when the game sends a simulated click. That ruins the automated sequence and makes the game do things it shouldn't.

So, I was asking if there is a way to essentially freeze the mouse in place during these simulated clicks. I would have the VBA code send like a simulated right or middle click which would freeze the mouse from manual movement, with VBA code simulate a movement of the mouse to the transparent button, simulate a left click to trigger the button, and then "thaw" the manual mouse movement with a second simulated right or middle click (or maybe have a specific time frame where the pointer would "thaw" after a certain amount of time).

The potential answer was to use simulated command of {LOCKXY} to freeze mouse movement with a potential {WAITMS} command to allow the manual mouse movement to be frozen for a certain amount of time. I couldn't ever get {LOCKXY} to work. It just refused. However, I was able to get {LOCKX}{LOCKY} to work. For whatever reason {WAITMS} caused instability with VBA, making the whole game crash. So, I abandoned it quickly.

I have found that even locking the x and the y with a simulated right or middle click, I am still able to move the mouse before the locking takes place. I guess there is enough of a delay between manually clicking the button that starts the VBA code doing the simulated right click which would trigger the locking of the X and Y axises and X-Mouse to actually do the locking for me to inadvertently move the mouse enough to move it off the transparent button; and, we are talking maybe less than a tenth of a second. Locking the axises helped, but it wasn't enough.

But now, the rest of the story. The way the game is setup, the transparent buttons that the simulated clicks are performed on are only on screen for much less than a second. Originally they were small buttons that appeared at the very lower left corner of the screen. So, because they only are onscreen (invisible, but still there) for a fraction of a second, and because of the way the game screen is setup, I was able to change the size of these buttons from being very small to make them fill about 70% of the screen, and be on top of (or above) everything else on the game board, without interfering with the game's operation. This meant unless I go crazy and make an extremely exaggerated mouse movement at just the right time, there is practically no way the transparent button can be missed by the automated clicks. Problem solved. I decided to use "cycle mouse cursor speed" set to 1 when doing the initial simulated right clicks and then back to normal speed on the second simulated right clicks. The VBA reacted better to it than the {LOCKX}{LOCKY}. But, this solution seems to work except in a very extreme, exaggerated situation.

Thank you so much for your help!