Is there any way to capture touch input on the screen (outside application frame) in windows device?
I'm working on a WPF application and can retrieve the touch input if it only occurs within the application frame. Also, is there a way to register the touch input even when the application is minimized?
There's no built-in method of the WPF framework that lets you listen for input outside of the application. If you want to do that, you'll have to get into p/invoke territory.
Specifically you'll need to create a hook. You'll want to look at the SetWindowsHookEx method and either the WH_MOUSE or WH_MOUSE_LL hooks.
Since you're dealing with touch inputs, this answer might have some useful information for you:
The lParam argument of your hookProc callback is a pointer to an MSLLHOOKSTRUCT. It contains a very poorly documented dwExtraInfo variable, which tells you whether it was generated from a touch.
If all of the bits in 0xFF515700 are set in dwExtraInfo, then the callback was invoked in response to a touch.
Related
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.
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'm working on writing an application that straddles the line between C# and C/++ on Windows Mobile 6.1/6.5. We currently have a kiosk application running on our devices, and would like to add the ability to switch back and forth to a second kiosk application.
Our goal is to establish a global hot key that switches process windows (similar to the way that alt+tab works) whenever it is pressed. We already have both applications and I've written some code that switches the processes, but am having a rough time getting the global hot key portion of the project working.
From all of the reading that I've done, my understanding is that the best way to monitor global key presses is to link into the system message pump with the SetWindowsHookEx function in coredll.dll. Unfortunately, I've also read that this function isn't technically supported on the platform.
I also found some tutorials that suggested using a message map with the ON_WM_KEYUP/ON_WM_KEYDOWN macros in the MFC framework, but couldn't find any documentation specific to Windows Mobile. When I tried to use the documentation here, my device kept crashing.
Is there an accepted best practice for setting some kind of global key hook on the platform? If not, is there something that's at least technically supported?
Thanks in advance.
ReplyQuote
Why not use a RegisterHotKey call and use that to swap applications? IIRC the hardware buttons typically map to key codes starting at 0xC1 (193).
We actually ended up polling the GetAsyncKeyState function in coredll.dll on a separate thread. The thread monitors a specific key, and throws an event whenever it is pressed.
Because the event is executed on the key polling thread, you have to be sure to use a delegate to invoke its handler on the GUI thread when the event is thrown.
I would go for a keyboard hook, but only if RegisterHotKey didn't work for your particular scenario.
From all of the reading that I've done, my understanding is that the best way to monitor global key presses is to link into the system message pump with the SetWindowsHookEx function in coredll.dll. Unfortunately, I've also read that this function isn't technically supported on the platform.
Not technically supported, is correct in theory, but I've not seen a WM 6.5.* device that hasn't supported it in reality. Keyboard hooking is such an important feature of vertical market custom rugged WM device apps that it I think it just cannot be removed, for backwards compatibilty.
The enterprise side of the WM space is too important.
I am trying to emulate "hardware" mouse clicks as it appears that some software blocks input from PostMessage for instance. I know there's SendInput, but that's not an option as I need this to be compatible in background windows as well. The solution seems to be a low-level mouse hook but I've searched around and couldn't find anything other than just the loggers, no manipulation of moving mouse, clicking etc. I'd like this to happen without having to write some sort of C++/C wrapper to use as a fake mouse driver.
http://support.microsoft.com/kb/318804, I found this but it doesn't seem to be of any further help.
Any help appreciated :)
Not sure what 'some software' might be, but sure, UAC stops you from poking messages into the windows of elevated programs. It is called UIPI, User Interface Privilege Isolation.
In general, faking input with PostMessage doesn't work well at all. It is especially a problem for keyboard input but mouse input has trouble too. There is no good way to alter the keyboard state for another process. That matters when the program checks the state of the Shift, Ctrl and Alt keys when it processes the input message. Many do.
The only real solution is to emulate input with SendInput(). Now you got a focus problem to solve.
mouse_event or SendInput used to inject mouse input. But just like a real mouse it's global input and can't work on hidden windows.
A low-level-mouse-hook is global too, but it is used to intercept and manipulate mouse-input, not to inject input.
When targeting a specific window you'll need to use SendMessage, but as you noted it doesn't work for everything.
You can also use dll hooking(for example an IAT hook) to intercept calls to APIs which return the gobal cursor position or the state of the mousebuttons. But for that you need to inject a dll into the target application, and that dll shouldn't use .net.
When I have to simulate mouse input I first try with SendMessage but sometimes some control or the application could eat the message.
In that situations I use spy++ to intercept messages of the window that holds the control, I do exactly what I want to simulate and then, I just use:
GetWindowLong(hwnd, GWL_WNDPROC);
to get window proc and then call the wnd proc(process) directly with:
CallWindowProc(WNDPROC lpPrevWndFunc, HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
Sending exactly those messages that I saw using Spy++. That always work because the window proc is called immediately instead of queued in the message loop.
Take a look at this library http://globalmousekeyhook.codeplex.com/.
It is 100% managed c# code to install global mouse and keyboard hooks.
I have an app that runs in the background (minimized/task tray). I need to be able to detect mouse activity (clicks, move) as well as keyboard activity.
What is the best way to do this given the constraint that my window is not "focused" ?
Take a look at this library globalmousekeyhook.
It is 100% managed c# code to install global mouse and keyboard hooks.
It wraps low level hooks into common windows forms keyboard and mouse events.
The magic words are windows hooks. These are created with a p/invoke call to SetWindowsHookEx. You can set up a hook to monitor, among others, keyboard and mouse events. Normally, such hooks are local to the application, but you can also create global hooks. The Microsoft KB shows how.
However, be aware that not all types of global hooks can be used from .NET. In particular, there are only two that you can use: the low-level keyboard and mouse hooks, known as WH_KEYBOARD_LL and WH_MOUSE_LL. Luckily, these are just what you need.