Develop Reference

C# Hooking specific Keyboard keystroke and stop system propagation

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.

How to simulate pressing a custom keyboard key

I have an extended keyboard and I want to simulate the key press of a special key that switches the keyboard mode. For that I think I need to find out key code, but can't figure out how can I get it. It's an extra key on my keyboard, not part of the ConsoleKey enum, and the only functions I've found to catch keys work with this enum.

If the key does something like change the keyboard color, this will depend on whether or not there is software on the computer which can do so as well. If not, this is probably just a local switch to the keyboard and that key isn't on the keymap for the keyboard itself, ether.
If it changes something else, it will depend on if there is driver software for the device or if it uses a default Windows driver.
If it takes installed software, it's probably a custom event (like some joysticks have) and would only be found if you use a reference to a library distributed by the keyboard manufacturer.
If it does not, then the switching mode is probably a "remap" mode tied to the keyboard firmware, and just changes which KeyDown event the affected keys send. If this is true, there is no way for Windows to even see what setting the keyboard is on.

I would say the logic for the function key changes is on the keyboard itself. For instance, the Fn key on my laptop does not cast any keyboard events by itself, but when combined with certain other keys, a key code is sent to the OS with a key code that triggers certain functionality.
For instance, in my keyboard Fn + Left lowers the volume, but the virtual key sent to the OS is VK_VOLUME_DOWN (see this for a list of virtual keys.)
Good news is, you can test the keys individually to see which key codes get sent to the OS! To accomplish this, you might want to set up a low-level keyboard hook) using P/Invokes.
There's a tutorial on CodeProject that may be useful to you.

Disabled CTRL-ALT-DEL, ALT-TAB and Start Menu C# [duplicate]

I'm working on an app (Written in C#) that have a setting to run on KIOSK mode. I've just an challenge here which is disabling Ctrl+Alt+Del combination Event.
There is no right answer in the similar past posts. Please let me know about the right action.
Considering, my code is working with registry keys to disable/enable options, if you know any registry key,it will be more helpful.

CTRL+ALT+DEL is the secure attention sequence of Windows NT (and its derivatives like Win7). It is the one key combination that is guaranteed to get the OS's attention. The whole point of the SAS is that it can't be intercepted or stopped by user programs.
One security issue it addresses is that of a false login screen: consider a screen that looks exactly like the normal Windows login screen. There's no way to tell that it's a fake just by looking at it. But, if you're in the habit of always pressing CTRL+ALT+DEL before logging in (there is an option to always require it for the legitimate screen), pressing the SAS on a false login screen will bring up task manager or the secure attention screen (with the log off, change password, etc options). The real login screen doesn't do that; it just stays there on the screen. As long as the OS itself isn't replaced or compromised, CTRL+ALT+DEL will protect you from false login screens. If a user program could intercept the SAS, it wouldn't be worth anything.
The SAS was baked into the Windows NT design right from the beginning (it was in the first release in 1993), so getting around it won't be easy. I'm sure there are keyboard filter drivers-- or something to intercept that sequence-- that are designed for kiosk use.

It is not possible to capture CTRL+ALT+DEL, it is so by design in all Windows systems. This is a security issue, if the user hits CTRL+ALT+DEL, he or she should be certain that it is the operating system and not some application (possibly a password-catching trojan) that responds to it.
I guess to capture CTRL+ALT+DEL you would need to write a device driver of some sorts.
Edit: Also see This answer. I did not try it, but the question is fairly similar.

Although it is sort of possible, it is not an easy task and not something that can be done in C#. This Article will show you how to disable CTRL+ALT+DEL using group policy editor. To permanently disable the combination though, you will either need to write your own keyboard driver or write your own GINA stub (Graphical Identification and Authentication).

It is possible to pick up the CTRL+ALT+DEL combination, but not to disable it.
I tried to disable it with SetWindowsHookEx and WH_KEYBOARD_LL and you can successfully get notified when CTRL+ALT+DEL is pressed, but you cannot do anything about it.

It is possible to block CTRL+ALT+DEL combination. However, you can't really disable it. As far as I know, there are two possible methods.
Remapping the keyboard layout. There is a registry binary key that allows you to remap keyboard layout:
HKLM\System\CurrentControlSet\Control\Keyboard Layout\Scancode Map
Please check this out: Disabling Windows Hot Keys
This method can be dangerous, but I haven't noticed any side effects this method can cause. The CTRL+ALT+DEL combination is handled by winlogon.exe. If your process has administrative privilege, you can suspend winlogon.exe. Hence, it cannot process the hotkey and nothing will happen if the user presses CTRL+ALT+DEL.
Please check this out: C++ code to disable CTRL+ALT+DEL.

You will need to do some P/Invoke, in user32.dll, there's a method called SystemParametersInfo, check out these resources for more info
http://pinvoke.net/search.aspx?search=SystemParametersInfo&namespace=[All]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724947%28v=vs.85%29.aspx
I did something similar a long while back, but no longer have the code, though I did find this (it's in vb6), but it shouldn't be too hard to get the idea and translate to .NET
http://www.developerfusion.com/code/1021/how-to-disable-ctrlaltdel/

Is it possible to block keyboard input selectively in Windows? How?

My app (in C#) need to interface with a USB bar-code scanner, which is basically working like a keyboard. It inputs the bar-code with an enter key at the end.
The app need to be work even when it's at background, so I am using low level keyboard hook to get and filter the bar-code out in the global key events. This part is already working.
Here is my problem: I don't want other apps to get the keyboard(scanner) inputs if it is a bar-code. And the normal key events should not be interfered. In one word, block the key events selectively. Is this possible?
My app is in C#, but I have no problem with C++ or more native solutions as long as it's easy to integrate in C#.
Thanks.
Additional Information：
The whole idea is working at background, even when it's not active. It watches the global key events stream and spot the bar-code sequence (already implemented with Hook). And most importantly, it do NOT interfere with normal keyboard events nor other applications' operation. That's why I cannot block all the key events or make it top-most.
I already can get the bar-code. I need to prevent other applications from getting the bar-code.

At the end of your keyboard hook you would call CallNextHookEx to execute next hook in the chain.
I would suggest that put some unique signature as a preamble for your barcode so that your keyboard hook procedure can detect it as a valid barcode input from your scanner. Now, when you get this data, just skip the call to 'CallNextHookEx' so that the chain will be discontinued and other programs won't get your barcode. Otherwise - call 'CallNextHookEx' so the chain can continue.
Note: This is my theory, I have never tried the exact same thing myself. I have however, written hooks in C++ and C#.

Check this project out
http://globalmousekeyhook.codeplex.com/
It is in C# as well so will make your coding easier. Sounds like all you need is to hook up the global key press event and suppress it by setting the Handled value or something similar.

Create an On-screen Keyboard

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