Closed wrapperup closed 5 months ago
Quick update, I noticed this:
I think this may be a factor in causing the issue, gonna try with just this removed.
I did a bit more testing and found that just removing the sleep was not enough, so I re-added the sleeps before setting the context back to 0.
Apologies for not getting back to you on this - I did try various combinations before and never really found anything that relliably worked. Changing sleep values around seemed to fix some things and break others. I have just made a major change in release 0.6.0 to how input is processed (See #75 ) which may make a difference. Also, I have noticed a potential flaw in how extended keycodes are processed which I plan on trying to address next. It may be worth re-investigating the issues with context mode to see if the latest version has improved things
No problem! Yeah, this PR may be irrelevant now (in retrospection, this PR only band-aided the issue...). Will try it out and let you know.
I noticed that in about 1/10 cases while pressing keys on my numpad keyboard, the key would fail to remap using the following AHK code:
During polling, the context state is set several times while a filtered device's keys get pressed. Looks like a race condition exists where AHK recognizes when a key gets pressed (when it checks cm.IsActive) and when the callback state gets set to 0, so to fix that I added a sleep before the context is set back to 0.
Haven't had a hitch yet with that change but I am trying some other ideas.