How to trap the keyboard strokes on a c# win forms

问题:

Is there Any way to handle the Ctrl+Alt+Del Key combination. Take for instance in a quiz application (Win Forms), the user should not be able to switch to other windows till the test is over.

I'm able to capture the Ctrl and Alt key strokes individually, using c# standard properties. but once they user hits the Del key . The control goes out of my appliation and windows handles it.

Any thoughts would be helpful.

thanks.

回答1:

Based on other answers, it seems that this is possible to do. Although I highly discourage this. Take for instance that your program should for some reason hang (god forbid...). Then you would have the situation that the only thing the user can do is to turn off the computer with the power button (or pull the plug...).

It is for a good reason that this is difficult to do, and the methods are poorly documented...

The only way this looks like the way to go, is the comment from Pierre-Alain Vigeant if this is a kiosk computer or something. Then it would actually make sense to do this!

回答2:

I don't think this is a good approach.

You are developing an application for the user and should not try to hinder his general actions.

For Alt+Ctrl+Del key combination read this article.

回答3:

AFAIK, Ctrl+Alt+Del generates a hardware interrupt and cannot be handled through software applications. Probably this can be handled through system-level keyboard hooks but I am not so sure about that either.

回答4:

Have a look here:

http://www.thescarms.com/vbasic/StopReBoot.aspx

Essentially for Win9x we trick system to think that the screensaver is running (which disables Ctrl-Alt-Delete sequence) and for WinNT we remap keyboard.

回答5:

Hmm, old topic without a real answer.

Short version:

• You need to use drivers to trap system key strokes
• To do so use the Interception Api which provides signed drivers for that purpose.
• To be able to use Interception you need to download and install the WDK (Windows Driver Kid)
• To test your program use a virtual machine with a test system. You do not want to test drivers in your running productive system.

Long version:

Yes, it is possible. To be able to intercept those key combination you need to provide a keyboard driver in the kernel layer. To explain why: In general there are two different types of key strokes in Windows. There are the system keystrokes (WM_SYSKEYDOWN or WM_SYSKEYUP) and the non-system keystrokes (WM_KEYDOWN or WM_KEYUP). Only the non-system keystrokes can be interrupted by a hook. Those keystroke messages are generated in the driver and then passed into the system-message-queue. If a WM_SYSKEYDOWN or WM_SYSKEYUP is inside this queue there is no possiblity on removing it before windows can handle it itself.

What can I do to prevent pushing System Key Strokes into the SMQ? Provide a signed driver to filter those. To create and to sign a driver yourself is not the easiest thing you can do. But there are APIs we can use. For example: Interception from oblita. That api provides signed driver to interact with the keyboards or lower drivers.

Reference for key events under windows: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646267(v=vs.85).aspx

回答6:

Set Form.TopMost to true, call Form.Activate() every millisecond and raise the process and entry thread priorities.

(Lo and behold the poor user which your application crashes on.)