Ctrl+Alt+Del (numpad Del) not intercepted

[r1me]

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

• Down: Code 0x53 State: INTERCEPTION_KEY_DOWN | INTERCEPTION_KEY_E0 (0 OR 2 = 2)
• Up: Code 0x53 State: INTERCEPTION_KEY_UP or INTERCEPTION_KEY_E0 (1 OR 2 = 3)

  Numpad Del (for both NumLock on and off)

• Down: Code 0x53 State: INTERCEPTION_KEY_DOWN (0)
• Up: Code 0x53 State: INTERCEPTION_KEY_UP (1)

Constant definition of Delete key in cadstop code looks like this:

InterceptionKeyStroke del_down = {scancode::del , INTERCEPTION_KEY_DOWN | INTERCEPTION_KEY_E0, 0};
InterceptionKeyStroke del_up = {scancode::del , INTERCEPTION_KEY_UP | INTERCEPTION_KEY_E0 , 0};

And then key that was pressed by user is compared, by checking keystroke code and state to be exactly the same as in constant:

return first.code == second.code && first.state == second.state;

in this case only Delete (not numpad version) key, will be considered as del_down or del_up.

Possible solutions for this issue

• A numpad version of del_down and del_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 with del_down and del_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.

[oblitum]

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:

• There's no invalid state for keys.
• Keys can't be up and down at the same time. There's a single state for all mouse buttons, hence its flags must be bitset-like to combine state change for all buttons, it must indicate when two buttons changed to down at the same time and it can't be a single 0 value. For keys this doesn't happen since state is for a single key, and it doesn't need to be bitset-like for down and up. Or it's down, or it's up.