I am using the blockinput API call, which blocks keyboard and mouse events while active. The only thing is by pressing ctrl, alt, del you unblock inputs. What I was thinking is to just change the keystroke of one of these keys, thus no ctrl, alt, del input could be achieved. I've had a look around and not got very far. Does anyone have any code to change a keystroke?


You did say about this problem........... Looks like I could use this approach tho, thanks. I've report on what happens when I play with it tomorrow.

Thanks again

The way the blocktest process works is fine on my XP none domain machine at home but the machines at work are domain machines and the ctrl,alt,del event produces a security box. I've tried adjusting the code to compensate for the different box name ie.

Private Declare Function BlockInput Lib "user32" (ByVal fBlock As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

Private Sub Form_Load()
retval = BlockInput(True)
End Sub

Private Sub Timer1_Timer()
retval = BlockInput(False)
End Sub

Private Sub Timer2_Timer()
retval = FindWindow(vbNullString, "Windows Security")
If retval <> 0 Then
    AppActivate "Windows Security"
    SendKeys "{ESC}"
    retval = BlockInput(True)
End If
End Sub

But this approach don't work. Is there away of reporting what the security box handle is, then I could use the handle in the FindWindow API?


I've used this code:

Private Declare Function GetForegroundWindow Lib "user32" () As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Private Sub Form_Load()
a = 1
Do Until a = 0
    retval = GetforegroundWindow
    MsgBox retval
    Call Sleep(10000)
End Sub

Which hangs vb and you have to end task, but it does give the handle of the current window. The handle of the "Windows Security" box is 0, which is strange........ But I thought hey, I could use the GetForegroundWindow API to loop and then act if the foreground window changed to 0. I shall look into it.....

My head hurts! :sad:

It looks as though the ctrl,alt,del event on these domain PC's stops the PC from reporting to any running app, thus the 0 handle. Which means that once this event starts, there is no way that vb can respond to this event. So it looks as tho the keyboard mapping is the only solution.

Any ideas?

Well, you could always look for .dll's that do system-wide keyhooks, and then trap the keysequence.... if findwindow returns 0, it did not find the window in question. You could always check for the classname of the window, and try it that way, but I think you are probably right about it not sending information to running apps. It might still respond to services, however, so you could try having your app run as a service in the registry, or look into building your app as a service. I would probably trap the keys with a systemwide keyhook, and discard the keypresses without sending them to the windows chain. Let me know what you come up with.

I've found this:


This is an interesting approach, it seems to work. It needs a reboot to work tho. So if I was to use it in an install account the user would have to login the mapping would get changed then the machine would reboot and autologin to complete the install and then the mapping could be removed and the machine rebooted a final time.

This poses another problem......Autologin, I've never done this before so any pointers greatfully received.


This article has been dead for over six months. Start a new discussion instead.