0

Is there any way to block the Keyboard input completely ? This should also block key combos like WIN+E.

I found this Code, is there anyway to change it to block only keyboard input (Mouse needs to work)

    procedure TForm1.Button1Click(Sender: TObject) ;

   function FuncAvail(dllName, funcName: string; var p: pointer): boolean;
   var
     lib: THandle;
   begin
     result := false;
     p := nil;
     if LoadLibrary(PChar(dllName)) = 0 then exit;
     lib := GetModuleHandle(PChar(dllName)) ;
     if lib <> 0 then
     begin
      p := GetProcAddress(lib, PChar(funcName)) ;
      if p <> nil then Result := true;
     end;
   end;

   var
     BlockInput : function(Block: BOOL): BOOL; stdcall;

   begin
    if FuncAvail('USER32.DLL', 'BlockInput', @BlockInput) then
    begin
     ShowMessage('Your Mouse and Keyboard will be blocked for 5 seconds!') ;
     BlockInput(true) ;
     Sleep(5000) ;
     BlockInput(false) ;
    end;
   end;

 end.

Would this code also work with WIN keys etc ?

Thanks!

TLama
  • 75,147
  • 17
  • 214
  • 392
user990767
  • 999
  • 1
  • 9
  • 15
  • 1
    `BlockInput` blocks all user input, you can't make it only block the keyboard. Why are you trying to do this? Perhaps we can come up with an alternative. – Polynomial Jan 31 '12 at 17:32
  • Hi, I need this for some kind of Kiosk-App, interacting with the screen will be done only with the Mouse. I don't want there to be any way to circumvent this, for instance press WIN+E and open the explorer. – user990767 Jan 31 '12 at 17:42
  • http://stackoverflow.com/questions/3236233/how-to-create-a-kiosk-like-ui-so-that-the-user-can-never-exit-from-it-or-switch – J... Jan 31 '12 at 17:44
  • 2
    Surely a global keyboard hook would be able to sort this out. Doesn't windows have a kiosk mode in any case. Or even better, just run your app as the shell. – David Heffernan Jan 31 '12 at 17:46
  • I saw and used the dWinlock API before, however this is a dll which I don't want to use, but since it can be done with this, I figured there has to be a way to also do it with code ? – user990767 Jan 31 '12 at 17:46
  • 13
    Why can't you take the keyboard away? – David Heffernan Jan 31 '12 at 18:03
  • also related: http://stackoverflow.com/questions/3156418/windows-global-keyboard-hook-delphi – Warren P Jan 31 '12 at 18:52
  • Are you able to capture any key presses and simply ignore them? – Matt Donnan Jan 31 '12 at 18:56

2 Answers2

8

You're thinking way too hard.

The appropriate way to set up a kiosk that can be controlled by the mouse and not the keyboard is to not have a keyboard attached. (This also makes it impossible for an unscrupulous kiosk-user to steal your keyboard.)

This also means that, if you need to perform administrative tasks, you can attach a keyboard (or remote in) and everything will work fine.

Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • 7
    Definately take away the physical keyboard, but also make sure the user has no access to run Windows' onscreen keyboard (osk.exe), either. – Remy Lebeau Jan 31 '12 at 20:58
  • You can hook `WndProc` and make it cancel all resize messages. They way you can't resize or minimise the window, or alter its z-order. You could then include an admin feature that disables that functionality, given a password. – Polynomial Feb 01 '12 at 06:46
2

If for some reason removing the keyboard is not a feasible option, there is an unsupported way of doing this in software: remove the UpperFilters value from

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}

This disables input from all normal keyboard devices, but the Remote Desktop virtual keyboard will still work, so you may want to ensure that Remote Desktop is configured and working first.

For your reference, should you want to reverse the process, UpperFilters is normally a REG_MULTI_SZ containing a single string "kbdclass" (without the quote marks).

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • Note that you need to reboot the machine in order for this to take effect. – Harry Johnston Feb 01 '12 at 02:18
  • +1, wow, never heard about this trick. However I would prefer a physical way to do so, probably a keylock switch controlling the power supply for the keyboard (USB). – TLama Feb 01 '12 at 07:02
  • 1
    @TLama: it depends on the context. I agree that removing or otherwise physically disabling the keyboard is probably the best solution for the OP, but there are scenarios where it isn't appropriate. In my case, for instance, I need to lock the input for hundreds of computers intermittently (and often) so it really does need to be done in software! – Harry Johnston Feb 01 '12 at 19:18