jim_s_w
asked on
Cathing keystrokes(/interrupts) from system.
Well, hello guys.
I have made a program (in Visual C++), and now i want it to react on userinput, not nessesarily given to the program. I mean, if the program runs in the background, then it should hook up on some interrupt (or something like that) so when the user hits some shortcut (e.g 'F10'), then the program should see this, and then do some work. I think it would be something like using the "signal(..)" in C, but it should catch keystrokes.... Know what i mean?
/Jim
I have made a program (in Visual C++), and now i want it to react on userinput, not nessesarily given to the program. I mean, if the program runs in the background, then it should hook up on some interrupt (or something like that) so when the user hits some shortcut (e.g 'F10'), then the program should see this, and then do some work. I think it would be something like using the "signal(..)" in C, but it should catch keystrokes.... Know what i mean?
/Jim
If you're running Win32 try out the API function GetAsyncKeyState(int key), which gives the status of the given key. As the parameter you can even pass 1 for the left mouse button, for example. You can also look for combined key hits like SHIFT+F1 by calling the function twice with the different key codes (VK_LSHIFT and VK_F1). GetAsyncKeyState works independently of which thread has the keyboard focus.
ASKER
Well, i tried it, and it works ok. But then i have to call 'GetAsyncKeyState' over and over. Is that applicable? I mean is that the way applications catch keystrokes, by continuisly checking for specific keys pressed (maybe with a short sleep between calls)? I was thinking about some way to tell Windows, "when any key is pressed, call this function at this address". Much like 'signal' in C. But i think that 'signal' in C only catched "Ctrl+C", "kill" and similar?
What you want to do is wait for some event to happen.
Therefore you must use one of the WaitForSingleObject() or related functions (WaitForMultipleObjects() for example).
Your problem is that the keyboard isn't automatically something you can wait on, if you just waited for stdin you would wait until your program got the focus etc which would never happen. In other words you need to make sure you wait for keyboard input - even if it isn't to your program.
How you get a handle to that I don't know you probably have to dig some but I am pretty sure it is the WaitFor... functions you must use when you find the correct handle to wait for.
One way to do it would be to capture the input focus, wait for key and as long as it isn't your key (F10 for example) you would send it on to whoever had the focus. This would be troublesome though. I see two problems with this:
1. The user would see graphically (visually) that the program he is working on does not have focus - this would probably seem unsatisfying to the user in that he would never completely know if his program had the focus or not since literally it would be your program having the focus at all times.
2. What if the key you chose was the key the user wanted to send to whatever program did have the input focus. If you chose F10, what if he wanted to press F10 and send it to the program he is using?
I know you have the idea from the old TSR's which often worked that way but that was typically in a non-windowing environment. With windows it simply isn't necessary to have applications that does that. If I want to activate your application I just start it and it pops up in another window and when I want to activate your application I ALT+TAB or click on the task bar to get it active. No need for a F10 or whatever to activate any application.
I would suggest you just drop the project and rather let people activate your program the usual way unless you have very compelling reasons for require such a 'hot key'.
Alf
Therefore you must use one of the WaitForSingleObject() or related functions (WaitForMultipleObjects() for example).
Your problem is that the keyboard isn't automatically something you can wait on, if you just waited for stdin you would wait until your program got the focus etc which would never happen. In other words you need to make sure you wait for keyboard input - even if it isn't to your program.
How you get a handle to that I don't know you probably have to dig some but I am pretty sure it is the WaitFor... functions you must use when you find the correct handle to wait for.
One way to do it would be to capture the input focus, wait for key and as long as it isn't your key (F10 for example) you would send it on to whoever had the focus. This would be troublesome though. I see two problems with this:
1. The user would see graphically (visually) that the program he is working on does not have focus - this would probably seem unsatisfying to the user in that he would never completely know if his program had the focus or not since literally it would be your program having the focus at all times.
2. What if the key you chose was the key the user wanted to send to whatever program did have the input focus. If you chose F10, what if he wanted to press F10 and send it to the program he is using?
I know you have the idea from the old TSR's which often worked that way but that was typically in a non-windowing environment. With windows it simply isn't necessary to have applications that does that. If I want to activate your application I just start it and it pops up in another window and when I want to activate your application I ALT+TAB or click on the task bar to get it active. No need for a F10 or whatever to activate any application.
I would suggest you just drop the project and rather let people activate your program the usual way unless you have very compelling reasons for require such a 'hot key'.
Alf
If you look back a couple weeks ago, you will see the same question asked, with several better answers.
cheers,
brian
cheers,
brian
ASKER
bkrahmer-> If you refer to 'Q_20554106' it talks about DOS environment, and not WIN32.
Salte-> I have checked the WaitFor...Object and they can not wait for key input. Only file changes, and events from specific threads and processes.
Other suggestions?
Salte-> I have checked the WaitFor...Object and they can not wait for key input. Only file changes, and events from specific threads and processes.
Other suggestions?
No, That probably wasn't it. There were specific windows API's mentioned. It may have been in the windows programming section or something like that. I think the solution you are after is a kernel hook via a device driver.
brian
brian
Actually, they can wait for any event provided you have a handle that can be 'signaled'.
If you have a handle to the keyboard you can use WaitFor on that handle.
The problem is to get a handle to the keyboard and to ensure that that handle will be signaled when the keyboard input arrives.
Absolutely ALL waiting in Win32 is done using some form of WaitFor... Even select() is implemented using WaitForMultipleObjects() in Win32.
To the OS the keyboard is a 'file'.
Alf
If you have a handle to the keyboard you can use WaitFor on that handle.
The problem is to get a handle to the keyboard and to ensure that that handle will be signaled when the keyboard input arrives.
Absolutely ALL waiting in Win32 is done using some form of WaitFor... Even select() is implemented using WaitForMultipleObjects() in Win32.
To the OS the keyboard is a 'file'.
Alf
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would assume that CreateFileEx() would do it, but you have to provide the filename argument that indicate the keyboard driver or some such. Also, check what command codes that driver has to make it signal the handle when a key has entered etc...
Alf
Alf
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Archived (PAQ) with a refund
Please leave any comments here within the next seven days. Experts: Silence
means you don't care.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
-bcl (bcladd)
EE Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
Archived (PAQ) with a refund
Please leave any comments here within the next seven days. Experts: Silence
means you don't care.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
-bcl (bcladd)
EE Cleanup Volunteer