Open r1me opened 8 years ago
Hi, thanks for the further clarification!
I think first option is the correct, besides being easier to understand.
The key setup is the way it's is on purpose, also internally, Windows works this way and the reasons are:
In cadstop example, a combination of Ctrl+Alt+Delete is intercepted, but if Delete key from numpad is used - it still goes through the filter (not intercepted).
Scan codes and state for Delete and Del (numpad) keys:
Delete
Numpad Del (for both NumLock on and off)
Constant definition of Delete key in cadstop code looks like this:
And then key that was pressed by user is compared, by checking keystroke code and state to be exactly the same as in constant:
in this case only Delete (not numpad version) key, will be considered as
del_down
ordel_up
.Possible solutions for this issue
A numpad version of
del_down
anddel_up
can be made like this:InterceptionKeyStroke numpaddel_down = {scancode::del , INTERCEPTION_KEY_DOWN , 0};
InterceptionKeyStroke numpaddel_up = {scancode::del , INTERCEPTION_KEY_UP , 0};
and then code expanded in function
shall_produce_keystroke
to use it along withdel_down
anddel_up
Instead of testing keystroke state value to equal constant definition, in custom == operator use OR that will allow combinations of INTERCEPTION_KEY_DOWN/UP and INTERCEPTION_KEY_E0.
return first.code == second.code && ((first.state | second.state) == second.state);
It is currently not possible to do this because key state enumeration begins with 0 so it will give false positives. i.e. 0 | 3 == 3, also 1 | 3 == 3
I believe second solution should be the right one. Key state enumeration should begin from 1, not 0. Zero should be used as "no/invalid/unknown/no action" state, so bitmask operations can be performed on valid key states.
For mouse buttons state enumeration begins from 1 which is technically more correct.
Keep up the good work.