hmmm, i got detecting control and alt states down, even which return key is being pressed, but i can''t, for the life of me, figure out how to do it with shift keys. alright, i know I could be using GetAsyncKeyState(), but i''m using this particular paradigm where instead of polling and checking every key, keystrokes cause a callback to fire with the particular keystroke as the parameter. On my machine, right now, the difference between a Left shift press and a right shift press is in the lParam parameter of WM_KEYDOWN. for the left shift, bit 19 is set, bit 20 is not. for the right shift these two bits are swapped... problem is--- bits 19 an 20 fall right smack dab in the middle of the OEM-specific scan code field of the lParam, which means this can and probably will for a different system. Not at all the general solution I was looking for.... any ideas anyone? Thank you for your bandwidth. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Succinct Demos Online~ "&ltDiLLiGaS> I''m suprised nobody takes M$ to court for rape... The OS keeps going down on you w/o your permission."

additionally, does anyone know how to stop the VK_LWINAPP and VK_RWINAPP keys from pulling up the start menu?

Surely you just need to check for the virtual key constants VK_SHIFT (for both) or VK_LSHIFT and VK_RSHIFT in the function GetAsyncKeyState?

Edited by - BloatWare on April 15, 2001 8:34:33 AM

I''ve done it that way before, bloatware, but that method doesn''t really fit my paradigm. The way i''m implementing my input module is to completely avoid polling for anything, and also, i''m trying to keep this in a class that completely abstracts the underlying API. My other modules that react to keys being pressed never see the API, as it is completely wrapped up in a Bridge type OO inheritance heirachy. The GetAsyncKeyState() cannot be part of this paradigm. The way i have it set up is to call my own registered callback function that is called after my wrapper module processes any of the WM_KEYDOWN family of messages. I suppose that, because the shift keys do, in fact, cause WM_KEYDOWN messages, that I could just check their states (which are saved in the wrapper) and check to see if any of the shift key''s states have changed. Hmmm, ok, BloatWare, maybe there is hope yet... more in a bit...