The title says it all. How can I ask my keyboard hook to tackle incoming keyboard message AFTER the parent window has processed them? Reading the docs I found there is a value named WH_CALLWNDPROCRET that does exactly this, but I need to specify WH_KEYBOARD there (to make it a keyboard hook of course), and the value doesn't appear to be a bit flag, so I can't combine both.
Background: I'm writing an add-in for Word 2013, which needs to monitor certain keys and take appropriate action only after Word has finished processing those keys. I'm using globalmousekeyhook project for hooking.
The library you are referring to is subscribing to following four hooks:
WH_KEYBOARD_LL
WH_KEYBOARD
WH_MOUSE_LL
WH_MOUSE
When you subscribe to a hook you give a system a callback to your code, which will be executed according to the rules which differ from hook type to hook type. Also the information the callback will deliver to you must be interpreted differently. These 4 deliver information about mouse positions, key strokes etc.
There are many different types of hooks you can subscribe to. See: Hook Overview
The WH_CALLWNDPROCRET yo are referring to is one of them. It has different callback invocation behavior and delivers you all messages sent to window. These may include theoretically any of hundreds of possible messages, not only keyboard and mouse messages.
To answer your question the library globalmousekeyhook can not subscribe to any other hooks than those 4 mentioned above.
Good news is that you can probably reuse code form the library to implement your own subscription.
You can reuse code to install the hook.
The signature of your callback will of course be different.
Then you will get all messages.
Filter out only those messages you are interested in e.g. WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP.
Interpret the data delivered along with messages. Also here you can reuse some code from the library.
Conclusion
No, the library can not do what you are looking for.
Yes, you can probably achieve that by reusing code from that library.
Related
I have an application where I have multiple keyboards connected through USB.
I need to hook a specific keyboard to get the keypress directly into the software, even if this one is not on the foreground. This so far works based on this project. The other keyboards shall work as normal.
Although it seems by using Direct Input, it is not possible to stop propagation (we don't want other apps to get that particular keyboard input).
Concerning Global Hook, it can block the keypress system-wise, but it is impossible, as far as I know, to identify the source of the keystroke (which keyboard it is from) and thus to selectively block them.
There is another project, here, that combines the two, but it is quite messy and heavy.
Is there a better way to achieve this? I am surprised that simple task is so complex.
If you are going to make the app windows only, you should look into Windows raw input api
It isn't that complicated.
I have to write an application in C# that listens to any keys being pressed. In actuality I have a bar code scanner sending the "key pressed" event, and I need to listen it... what it does from there is beyond the scope of my question.
My security requirements are that there is not allowed to be any sign-on to the machine in any way shape or form AND this must run as a windows service. The user will start the machine and walk away (i.e., no desktop session).
I'm assuming I'm going to have to go unmanaged for this.
Given the security requirements is this even possible? If so, any pointers on where to start would be great.
Thanks in advance,
Jay
Try keyboard and mouse hook
http://www.codeproject.com/KB/cs/globalhook.aspx
You will have to learn pInvoke with combination of learning how to look for the right events produced at the lower level of OS. By calling into user32.dll using pInvoke your managed code can filter those events through the hooks.
http://pinvoke.net/default.aspx/user32.SetWindowsHookEx
If you need to see keyboard presses for all apps, system-wide Hooks would be the way to go normally, but the problem is that the security changes in Vista and above make hooks rather less useful. A process cannot hook another process at a higher integrity level, so there's no guarantee you will see all events.
However if you only need to see events going to a particular app - the one reading the bar codes - then provided you can identify that process, a thread-specific hook will suffice and the integrity question will not arise.
I have an application which has a form, but the fact that it has a form is irrelevant.
With this app, I need to listen to all Operating System level Touch events. Basically I need to capture that the screen has been touched no matter which form has focus, gather all the info like coordinates etc. and then do whatever with it.
I'll actually be sending it on to another app via a Windows Message but that's not relevant either. I just need to know how to listen and capture ALL OS level touch + drag events etc.
You can read HID data directly, using a Raw Input API and to parse it by yourself.
In general:
Find Hids and store preparsed data.
Register for input events
On WM_INPUT event parse buffer using HID API functions and preparsed data.
This link explains the topic of keyboard/mouse event hooks.
It is a rather advanced subject however, filled with lots of low-level interop. I'd avoid such a task and try to come up with a different solution for this. What is your final goal with this application?
I use PostMessage to simulate keystrokes in a program that is in the background. It work fine except for characters that need shift on the physical keyboard. How do I simulate shift? "
The code I use is roughly:
VK vk = VkKeyScanEx (c, GetKeyboardLayout (0));
AttachThreadInput (_attachedThredId, _attachedProcessId, true);
PostMessage (_window, WM_KEYDOWN, vk.key, 0x1);
PostMessage (_window, WM_KEYUP, vk.key, 0xC0010001);
AttachThreadInput (_attachedThredId, _attachedProcessId, false);
How should I handle Extended part of VK?
Edit
I'm trying to create an on-screen keyboard. Each button on the on-screen keyboard simulates a sequence of keystrokes. The receiver is an old program that performs different tasks depending on the keyboard sequence that is performed.
Keyboard sequences is as follows
{ESC}NN{ESC}NN
{ESC}NN
½NN
§NN
where {ESC} simulate pressing the Esc key, NN are hex values and §/½ get the program to listen.
Normally we have special physical keyboard to control the program, but they are expensive. So in a test environment where we do not always have the physical keyboards, we have to enter these codes manually
You must compromise:
If you want to simulate keyboard input, then you must use SendInput, which means being at the mercy of which window currently has focus. SendInput is like hitting the keys on your physical keyboard. The only way you can send your keystrokes to a specific window using your keyboard is to ALT+TAB to the right window.
If you want to send keystrokes to a specific window, then you incur funky behavior:
Applications handle input differently. And simple WM_KEYDOWN / WM_KEYUP messages are not the only way to detect keyboard input. For example there is also the keyboard state (GetKeyboardState()) which you will have a harder time simulating. This is most likely what you're experiencing.
Applications may RELY on the standard behavior of having focus while receiving keyboard input messages. By posting messages to these applications, you invoke strange out-of-order behavior that may crash them.
Now multiple windows on the system can be receiving keyboard input at the same time. This might also cause strange behavior.
(etc...) Hooks won't be called for this input, your keyboard / input drivers won't see it, it won't be recognized by things like DirectInput... basically it's a never-ending patchwork of issues by doing something the bad-bear way.
There is no way around those side-effects; it's the consequence of doing shady stuff.
A solution for your purposes, because you're targeting a single specific application, may be to use PostMessage in conjunction with SetKeyboardState to simulate the keyboard state including shift positions.
Okay, I think you're in for a mess here, PostMessage() is notorious for not working well with shift states, and hooks won't get called either. Microsoft recommends SendInput() instead, and so do I. I suggest that you either post a new question, or update this one, where you detail what you are trying to achieve, and maybe we can better recommend a different solution.
As for the extended part, it has nothing to do with this at all, and won't help you.
What you could try, is sending a WM_KEYDOWN message that says the shift key was pressed, and then send another message with your desired key, before sending a WM_KEYUP shift message. I doubt this will work, but you can always try.
Personally i would use SendKey.Send( ) for this purpose.
MSDN page
I have to write an application in C# that listens to any keys being pressed. In actuality I have a bar code scanner sending the "key pressed" event, and I need to listen it... what it does from there is beyond the scope of my question.
My security requirements are that there is not allowed to be any sign-on to the machine in any way shape or form AND this must run as a windows service. The user will start the machine and walk away (i.e., no desktop session).
I'm assuming I'm going to have to go unmanaged for this.
Given the security requirements is this even possible? If so, any pointers on where to start would be great.
Thanks in advance,
Jay
Try keyboard and mouse hook
http://www.codeproject.com/KB/cs/globalhook.aspx
You will have to learn pInvoke with combination of learning how to look for the right events produced at the lower level of OS. By calling into user32.dll using pInvoke your managed code can filter those events through the hooks.
http://pinvoke.net/default.aspx/user32.SetWindowsHookEx
If you need to see keyboard presses for all apps, system-wide Hooks would be the way to go normally, but the problem is that the security changes in Vista and above make hooks rather less useful. A process cannot hook another process at a higher integrity level, so there's no guarantee you will see all events.
However if you only need to see events going to a particular app - the one reading the bar codes - then provided you can identify that process, a thread-specific hook will suffice and the integrity question will not arise.