1

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.

Druid
  • 6,423
  • 4
  • 41
  • 56
vijaysylvester
  • 4,750
  • 7
  • 29
  • 41

6 Answers6

5

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!

awe
  • 21,938
  • 6
  • 78
  • 91
  • But i took up an online test . it had the quoted features incorporated – vijaysylvester Aug 26 '09 at 15:01
  • See RRUZ's answer, the second link is amazing – Andomar Aug 28 '09 at 12:42
  • @Andomar - Yes, I looked at that link. And the sollution was one of two: 1. Disable the task manager in registry (not trap the keybord event) which caused a message to appear that it was disabled. 2. Write your own MyGina.dll that overrides the default functionality of Ctr + Alt + Del. Both these methods are "hacking" the system by doing permanent changes to the system. I think none of these are in the scope of just just disable the key sequence during the running of a quiz application. – awe Aug 31 '09 at 06:18
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.

rahul
  • 184,426
  • 49
  • 232
  • 263
  • 1
    if that is the case , all online students taking up the test , can get the answer from google(by changing to browser). – vijaysylvester Aug 18 '09 at 09:09
  • They can use another machine or use a book also to get the answers. – rahul Aug 18 '09 at 09:34
  • 1
    Access to another machine or a book can be handled. Not blocking Ctrl-Alt-Del and allowing them to run a browser instance is making it way too easy. – Jim Aug 18 '09 at 09:47
  • Would it not be handier to somehow disable the browser(s) on the machines that the test will be running on? Have them log in as a user that can 'only' run your test... – Paddy Aug 18 '09 at 12:48
  • 1
    what if the user not allowed to do any thing other than taking the test.? that would be more meaning ful. – vijaysylvester Aug 26 '09 at 15:02
2

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.

Aamir
  • 14,882
  • 6
  • 45
  • 69
0

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.

DmitryK
  • 5,542
  • 1
  • 22
  • 32
0

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

Fjolnir Dvorak
  • 316
  • 3
  • 13
-1

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.)

Cecil Has a Name
  • 4,962
  • 1
  • 29
  • 31