[BUG] {PRESS} and {HOLDMS} don't release key sometimes

[Soulfate]

1) 2.17 Beta 15 (but also with 2.16.1) 64-bit (didn't test with 32-bit)
2) Windows 10 LTSB 64-bit
3) LMB+MMB+RMB + 4 + 5 + MWUP + MWDOWN
4) Generic HID device
5) No other mouse software installed

In a game (64-bit, not admin), with {PRESS}/{RELEASE} or {HOLDMS} function, some keys stay pressed if I release during a loop.
Example :
- Simulated Keystrokes
- Only send if profile's process is active ticked
- 6 Repeatedly while button is down (200 ms)

Code: Select all

{PRESS}4{WAITMS:20}{RELEASE}4fff{PRESS}f{WAITMS:50}{RELEASE}f{PRESS}t{WAITMS:20}{RELEASE}t{PRESS}t{WAITMS:90}{RELEASE}t

In this example, keys T or F may stay pressed down if I release button during the loop, assuming it has not ended (before 200 ms).
It's only one key that stay pressed, never more (T and F cannot stay pressed both, it's one or the other, depending when I released the mouse button).

Other example :

Code: Select all

{HOLDMS:50}3{HOLDMS:50}3{HOLDMS:50}3

Keystroke 3 may stay pressed down too if I release button during the loop (high risks to happen).

Delay between simulated keystrokes is 1 ms.

Is it a XMBC bug or game/DX9 problem?
How to avoid this issue?
Thank you!

[phil]

Probably an XMBC bug. The code to break halfway through a loop is fairly new and its a tricky bit of logic (what have we pressed, what do we need to release etc).

I guess the problem is, if you break the loop after a press and before the release, the release wont be executing... But I suspect the solution/fix is not going to be so simple as stating the problem as I thought I had already accommodated this (in 2.17 betas) but clearly not.

Best way to avoid it right now (until I can fix it) is not using {PRESS} and {RELEASE}!

Thanks,
Phil

[Soulfate]

Ok thank you and what about adding another option in Simulated Keystrokes that execute commands only when I release the button? Or maybe split "on press" and "on release" events and make them both available for Simulated Keystrokes.
For example, I my example, doing the loop while the button is pressed down and only on release of the mouse button, do something else (why not a force {RELEASE} that i've manually set to fix the issue, or even to let me do other keys that are not in the loop). That could bypass the problem and maybe adds nice missing options for XMBC!

[phil]

There is already an option to send when the button is released... that's method 2...
But that's not what you mean is it...

Do you mean have an extra field for things to do when released... then really you might want 3 fields, press, hold and release.. Quite frankly thats just too much work (completely rewriting the simkey code and gui) so that's not likely to happen any time soon (my time is very limited these days)..

I'll see if I can figure out why the current code is not working, because it should release anything it has pressed when breaking the loop.

Thanks,
Phil

[Soulfate]

That's ok
I want to help you to fix the "non releasing" bug and today, with some tests, I've seen that in some cases (very rares), a simple Keystroke (for example just an "A" in the sequence, without {HOLDMS} or even {PRESS}) can block itself to "pressed down". It was surprising, there was no holding option for "A", but it stayed pressed down. It was of course in a sequence with {PRESS} and {HOLDMS}. I guess that I've "perfectly" released my mouse button when XMBC was processing the "A" part.
In another loop of 200 ms, I've tried just this

Code: Select all

a{WAITMS:30}a{WAITMS:30}a{WAITMS:30}a{WAITMS:30}a{WAITMS:30}

It's very rare, but with some try, I've been able to bug "A" to "pressed down".
Good luck and take care of yourself before all