I've developed a WPF application that registers Hotkeys using com interop and processes them using WndProc.
The hotkeys work perfectly even when the application doesn't have focus. However, they don't work when certain fullscreen appications have focus (games). Is there a way for me to fix this?
Thanks!
The disabling of hotkeys is by design and as far as I know not much you can do about it.
Full screen DirectX applications (typically games) will call IDirectDraw::SetCooperativeLevel with the DDSCL_FULLSCREEN and DDSCL_EXCLUSIVE flags which results in, amongst other things, the registered hotkeys being disabled.
Even though registered hotkeys are disabled, you might be able to process your hotkeys via a low level keyboard hook. They can be kind of tricky to implement right, but you can look at the AutoHotkey source to see how it handles hotkeys in a low level keyboard hook.
This is a good tutorial on setting up a low level keyboard hook in C#.
Related
I've an application(C# 4.0-WPF), which is hidden and can be displayed by clicking on the systray icon or on an other frame I created(small frame which is docked left and topmost).
My customer wants to add a new way to display the application: When pressing on a "F" key (e.g. F9).
How do I know in my application if the user presses this key when the application is not the current window /or is not focused?
Global keyboard hooks are not the right solution if you only want a few global hotkeys.
A global keyboard hook using WH_KEYBOARD means that your dll will be injected into every process that receives key presses. It should not be used at all in managed code, since the CLR is relatively heavy weight and may cause version conflicts.
This code injection will also look suspicious to anti-virus software, which might block it.
A low level keyboard hook using WH_KEYBOARD_LL is a better choice for managed code, since it processes the keyboard events in your own application. Still it requires that every keyboard event is handled by your thread.
This increases the time between a key being pressed and the target application receiving it.
This is particularly bad if an application with higher CPU priority than your application starves it of CPU time. In that case the latency can reach several seconds, bunching many keypresses together. Some (badly written) games work like that and become unplayable in such a situation.
The windows API function RegisterHotKey is the proper function to use for global hotkeys.
Windows will do the filtering for you, and only notify your application if one of the registered keys has been pressed, so you don't have to process all of them.
Using a simple F-Key as global hotkey, as you plan on doing, is problematic since it often collides with a local hotkey of the application that has focus. So you should make global hotkeys configurable, so the user can avoid collisions with their commonly used applications.
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 a C# .NET 2.0 application running on client kiosk machine (Windows XP) that occasionally puts up a window for user input. The other kiosk software seems to be interfering with it somehow because while it is running our window will not receive Mouse or Keyboard events despite it being the top window. When the other software is not running all works as expected. Does anyone have any insight as to what might be going on here?
Thanks
If in doubt - use Spy++ provided with Visual Studio to see what messages your window receives from the system.
If the other application blocks all input, it's not conforming to the Win32 API. That's why the low level hooks timeout was introduced in Vista and newer Win OS. Meaning a process would be kicked out of the low level hook chain, if it held onto a hook too long before calling CallNextHookEx() and not receive any low level hook messages anymore.
On Windows XP, there is no such limitation. A process can take as much time as they want to process a hooking message. The other program is either buggy, or evil. If it's essential that your application has input, then just close the other one programmatically or contact the author of it and explain the situation.
Take a look here
http://www.codeproject.com/Articles/7294/Processing-Global-Mouse-and-Keyboard-Hooks-in-C
Using global keyboard hook should do just fine and some sources are included as well. Also, some user seem to solve similar problem by using ManagedSpyLib:
https://stackoverflow.com/a/8829286/1284902
After some digging, it is possible that the other windows forms program is utilizing a low level keyboard hook similar to one found here http://blogs.msdn.com/b/toub/archive/2006/05/03/589423.aspx. After following a link in that article, I came across a summary of that code snippet
For a concrete example of this, consider the (buggy) code in Figure 4. Using a low-level keyboard windows hook, the code intercepts all WM_KEYDOWN messages sent to any window and prints out the corresponding key.
Source: http://msdn.microsoft.com/en-us/magazine/cc163606.aspx
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 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.