On Thu, 2005-03-31 at 07:48 +0200, Adam Kłobukowski wrote:
That is the basic idea, but note that I wish that Shift, Control, Alt to
be reported like other keys, so application could know that Shift, Alt,
Control are pressed alone.
Oh yeah. In the proposed hack^h^h^h^h "interface modification", the KEYSTATE event would report the status of the "modifier" keys as well. You wouldn't get the ascii equivalent, but you'd get the scancode in the key portion and the status of the keys in the usual place, when they go up or down.
For example, when CONTROL goes down, you'd get the scancode for the control key in the upper 8 bits of the keyboard key, nothing in the lower 8 bits since there is no ascii value and 0x04 for the keyboard state. For Control going up, you'd get the same scancode for the key value, but the keyboard state variable would be blank. This would either require a couple of #define's for the scancodes of the modifier keys to check there, or if you want to allow multiple keys at once, the programmer might want to keep track of the previous state of the keyboard modifier keys so you can see what transitioned.
This is basically what I used to do for mouse buttons anyway (if I remember this correctly - its been 10 or 11 years, but its coming back!). Instead of waiting for a specific button, toss in the last button state, OR clicks with 0x0100 to wait for the buttons to NOT be in that state. Then compare the returned button state with the previous one to see which button(s) were pressed. Double and triple clicks are returned, although hopefully only 1 button transitioned if you get more than 1 click. This way you can get mouse click, mouse down, and mouse up, and for all mouse buttons, basically what you want for keyboard keys. Then before calling evnt_multi again, set the previous mouse button state to the one that was just returned. You'd basically be doing the same with the keyboard.