simulated key press (during) not released

x64 Replacement/Alternative to Microsoft's IntelliMouse application.
Forum rules
Please read the forum rules before posting for the first time.
The more information you can provide, the quicker and more accurately someone can help.
Post Reply
yzahn
New User
Posts: 3
Joined: Sat Jan 05, 2019 10:25 pm

simulated key press (during) not released

Post by yzahn » Tue Jan 29, 2019 2:36 pm

XMBC Version: 2.18 an upwards
Windows Version: 10, 1809
Mouse Information (brand/model):
Computer Information:
Did the problem occur after an upgrade of XMBC or Windows?: after upgrading from latest 2.17
How long have you used XMBC?: a year or so...
What language and keyboard layout do you use in Windows?: en-us

Clear description of the problem:
Hi,
I have configured XMBC to allow `ctrl+scroll`ing in adobe programs e.g. InDesign (instead of the inbuilt `alt+scroll`ing).
The way I implemented it is:
- ctrl => go to layer 2.
Now in layer 2:
- wheelup & wheeldown => Simulated Keys: (during)[{ALT}] (don't block original mouse output)

This worked fine until updating to 2.18, after the update, for some reason the Alt key isn't released even after the scrollup or scrolldown event is over. This cause further scrolling to zoom the display even whithout pressing alt or ctrl.

Any ideas how to fix?

User avatar
phil
Site Admin
Posts: 5826
Joined: Sun Apr 06, 2003 11:12 pm

Re: simulated key press (during) not released

Post by phil » Tue Jan 29, 2019 10:44 pm

Sending keys on a wheel move is never a great idea, because there is no down / up message. Have you turned on "Ignore repeated remapped vertical scroll" in the options tab for the profile? If not, then during will not work on the wheel - and I don't really understand how it could have worked in 2.17 unless by some miracle of timing you got away with it (2.18 is faster and uses less resources in general so that may be the problem).

Also if you are holding CTRL to switch to layer two, then you will actually be sending CTRL+ALT+Scroll to the application (as you are holding CTRL for layer 2) - is this what you are trying to do?

Finally, by sending {ALT} and turning off leaving "block original input" you are at the lap of the gods timing wise - but for sure, the mouse wheel message tha is not blocked will occur before the ALT key is pressed - so that makes little sense to me.

There may be a way to get this working, but quite frankly, on the wheel, with no down/up message your asking for trouble!

There was a bug in 2.18 (fixed in 2.18.1) where the "during" actions didn't release properly - that may have had some impact (although the fix should have made that good again). But there a chance that the fix is not working correctly on the wheel operation (with the simulated up message) and maybe that's the problem.

I'm on holiday for a few weeks and I'm out of the country with little chance/time to look at email/forums never mind look at the code. So I'm afraid any investigation will have to wait until I return. Remind me in a couple of weeks if you don't hear back from me sometime after the 10th Feb.

If you need a link to 2.17 then let me know and I can dig that out for you.

Regards,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

yzahn
New User
Posts: 3
Joined: Sat Jan 05, 2019 10:25 pm

Re: simulated key press (during) not released

Post by yzahn » Tue Jan 29, 2019 11:08 pm

Thanks for your reply.
phil wrote:
Tue Jan 29, 2019 10:44 pm
Have you turned on "Ignore repeated remapped vertical scroll" in the options tab for the profile?
Honestly, I don't currently understand what that setting does, but I just tried it now and it doesn't seem to make a difference.
phil wrote:
Tue Jan 29, 2019 10:44 pm
Also if you are holding CTRL to switch to layer two, then you will actually be sending CTRL+ALT+Scroll to the application (as you are holding CTRL for layer 2) - is this what you are trying to do?
I do not need the ctrl key to also be sent to the app, but it doesn't seem to disturb.
phil wrote:
Tue Jan 29, 2019 10:44 pm
Finally, by sending {ALT} and turning off leaving "block original input" you are at the lap of the gods timing wise - but for sure, the mouse wheel message tha is not blocked will occur before the ALT key is pressed - so that makes little sense to me.

There may be a way to get this working, but quite frankly, on the wheel, with no down/up message your asking for trouble!

There was a bug in 2.18 (fixed in 2.18.1) where the "during" actions didn't release properly - that may have had some impact (although the fix should have made that good again). But there a chance that the fix is not working correctly on the wheel operation (with the simulated up message) and maybe that's the problem.
I am on the latest version (2.18.2) and still not working.

Unfortunately, I haven't quite understood your points what I have done wrong and what would be a correct way of achieving the desired result, so enjoy your holiday! and meanwhile I will try to read the docs and reach a better understanding. :)

yzahn
New User
Posts: 3
Joined: Sat Jan 05, 2019 10:25 pm

Re: simulated key press (during) not released

Post by yzahn » Tue Jan 29, 2019 11:32 pm

Actually I see your point and yeah, perhaps this shouldn't work :) but seeing as it does work, and the only problem is that the ALT key isn't released, perhaps this is related to the bug you mentioned...

Enjoy your holiday, and waiting to hear from you!

User avatar
phil
Site Admin
Posts: 5826
Joined: Sun Apr 06, 2003 11:12 pm

Re: simulated key press (during) not released

Post by phil » Wed Jan 30, 2019 8:53 am

Just to try and clear things up a little (I know you said you understand it more now - but for the benefit of all)...

A mouse button sends Windows two messages; a Pressed (down) and Released (up) message.
Therefore you can use "during" in sim keys, so when the button is pressed down, the simulated key is pressed down and when the button is released, the key is released - hence the key is held down while the button is held down.

The mouse wheel does not send distinct pressed & released messages. Instead it sends a single message to say "scroll delta (x)" which repeats for each notch on the scroll wheel and where delta is a positive or negative number to indicate direction.

Because there is not a down & up message, there is no concept of "during" for the mouse vertical scroll wheel (or horizontal tilt).
XMBC can attempt to simulate a down and up, using the option to "ignore repeated remapped vertical/horizontal scroll" where by the first scroll message simulates a down, and a timer is fired after x milliseconds to simulate the up message. If another scroll (or tilt for horizontal) message comes in before the timer expires, the timer is reset. There by simulating a "duration" (from first scroll message to x milliseconds after last scroll message) for which a simulated key can be held down. But its not 100% reliable as it depends on how quickly you scroll etc.

So that's why I don't understand how it worked before... But as you say, it did work before. So I need to try and figure out why, and maybe it is related to the bug fixed in 2.18.1.

Regards,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

Post Reply