How do you disable: "^" "!" "#" "F4" etc..

[schilbiz]

I am making a kiosk system that will only be available to a shared user account. What I need to do is make a script that will disable the use of ctrl+alt+del, alt+f4, ctrl+esc, ctrl+shft+esc, and the windows key (#) in AutoIt.

This user(s) will log in periodically to a kiosk interface and have to be able to type a few things, search for some information and do basic input output stuff then print a report. So they need to be able to use the keyboard and mouse, but shouldn't need the alt, ctrl or window keys. This would just be put in the login script by GP for this individual user account.

I have found a few examples via the search engine but half of them don't work for this, or do too much, e.g. disable the mouse and keyboard entirely, or one or the other.

I found this one that manadar suggested, but it doesn't work when you input ! ^ # etc... Thanks.

HotKeySet("e","nothing")
HotKeySet("d","nothing")
HotKeySet("a","nothing")
HotKeySet("+a","nothing")

While 1
Sleep(1000)
Wend

Func nothing()
EndFunc

[PsaltyDS]

It would make much more sense to use a Restricted Shell.

Check out Mapping Managed Configurations to User and Computer Roles and look for the "Highly Managed" and "Kiosk" configs.

[Albuquerquefx]

If you truly want to disable those keys, I have only found ONE way to make it work 100% of the time. Unfortunately, this is an OS change and so requires a reboot both to enable and to disable. Fortunately, it's a change that is administered through the registry, so your AutoIT script can apply the registry entry and on the next powercycle it will "just be there".

Here's the problem: this is UGLY. I warned you

Microsoft Developer Network knowledgebase article on scancode mapping: http://www.microsoft.com/whdc/device/input/w2kscan-map.mspx

And you'll need to know the scancodes of the keys you wish to remap: http://www.randyrants.com/sharpkeys/

Here's an idea -- dont' remap ALL the keys, just remap the ones that are common. We wanted to kill off ALT-F4 and CTRL-ALT-DEL. Well, you don't need to remap five keys, you only needed to remap one: ALT. Once it's "broken", the key-combo functions that rely on the ALT key stop working too.

Restoring the keyboard back to default is as simple as deleting the registry key described in that MSDN article. But again, this isn't an instant-on / instant-off process. It requires a reboot to enable, and a reboot to disable.

[schilbiz]

@PsaltyDS and Albuquerquefx, Appreciated, interesting information.

I already have the kiosk setup and in place but during my break/fix testing I found that alt+F4 and ctrl+esc still work.

Is there a way to reassign a key to something else via regedit, just for that single session? Like make Alt = spacebar.

http://www.microsoft.com/whdc/device/input/w2kscan-map.mspx

The Scan Code Mapper has several advantages and disadvantages. The advantages include:

The Mapper can be used as an easy fix to correct firmware errors.

Frequently used keys can be added to the keyboard by modifying the map in registry. Keys that aren't often used (for example, right CTRL key) can be mapped to null (removed) or exchanged for other keys.

Key locations can be altered easily. Users can easily customize the location of frequently used keys for their benefit.

The following disadvantages are recognized:

Once the map is stored in the registry, a system reboot is required to activate it.

The mappings stored in the registry work at system level and apply to all users. These mappings cannot be set to work differently depending on the current user.

The current implementation restricts the functionality of the map such that mappings always apply to all keyboards connected to the system. It is not currently possible to create a map on a per-keyboard basis.

[Albuquerquefx]

Not at an OS-level there isn't, at least according to Microsoft.

I guess in theory you could write your own keyboard driver, and "drop" the keys that you don't want. You could then swap the HID driver for your keyboard on the fly, and I believe that would take effect immediately versus a reboot.

But if you're that good, then I'd say do it and lend me a free copy

[piccaso]

Did you try setting up a Hook which 'eats' certain scan codes?

[Albuquerquefx]

keyboard Hooks would only work if you wrote yourself a program in C#, or else you built / found a DLL that would allow you to do a DLLCall function. There isn't any "stock" interface to that functionality in AutoIT that I'm aware of.

And hooks can be precarious things; they're quite timing dependent. If your hook app doesn't acknowledge the event in a specific timeslice, the hook will get passed back to the system for further work. It would be far easier to remap the key(s) through altering the scancode than it would to write a keyboard hook IMO

[schilbiz]

Did you try setting up a Hook which 'eats' certain scan codes?

I was just reading about Hook as well as a few other ones.

I found this one KeyTweak, http://webpages.charter.net/krumsick/

Which seems pretty handy and simple, but I am going to keep looking into being able to do it without having to reboot the computer.

[Albuquerquefx]

I was just reading about Hook as well as a few other ones.

I found this one KeyTweak, http://webpages.charter.net/krumsick/

Which seems pretty handy and simple, but I am going to keep looking into being able to do it without having to reboot the computer.

Heh, that Krumsick utility is a GUI interface to the reg key I posted above. Microsoft doesn't provide any other way to remap those "special" keys unless you're working with an HID driver...

[ako673de]

I have noticed, that 6 regular keys are not redirectable via HotKeySet. These are "{", "}", "+", "#", "!", "^" and that obviously has to do with their usage as "SpecialKeys" to indicate "Shift", "Ctrl", "Alt" and "Win".

The AutoIt help however states that they should be accessible via "bracketing" (e.g. "{!}" for "!") just like it works for the "Send()" function.

I'm not completely sure, but to me it seems that we found a bug in AutoIt, especially because some of these keys still can be accessed by using special keys ("!" can be accessed by "+1", "{" can be accessed by "!^+(", "{" can be accessed by "!^+="). Of course this has an untolerable side-effect: It makes the function depending on the keyboard-layout. But I think the more important information is, that most probably it is not a system restriction we are talking about.

Can anybody comment on this? If I'm right, is it possible, that the native HotKeySet-function of WinAPI works better? If so, how can I use that (I'm not so familiar with the calling scheme of this WinAPI function - especially with it's parameters like "virtual key codes" or so).

[jennico]

I have noticed, that 6 regular keys are not redirectable via HotKeySet. These are "{", "}", "+", "#", "!", "^" and that obviously has to do with their usage as "SpecialKeys" to indicate "Shift", "Ctrl", "Alt" and "Win".

The AutoIt help however states that they should be accessible via "bracketing" (e.g. "{!}" for "!") just like it works for the "Send()" function.

I'm not completely sure, but to me it seems that we found a bug in AutoIt, especially because some of these keys still can be accessed by using special keys ("!" can be accessed by "+1", "{" can be accessed by "!^+(", "{" can be accessed by "!^+="). Of course this has an untolerable side-effect: It makes the function depending on the keyboard-layout. But I think the more important information is, that most probably it is not a system restriction we are talking about.

Can anybody comment on this? If I'm right, is it possible, that the native HotKeySet-function of WinAPI works better? If so, how can I use that (I'm not so familiar with the calling scheme of this WinAPI function - especially with it's parameters like "virtual key codes" or so).

well,

we've been discussing that problem in the other thread. the essence is:

- will be fixed in next beta.

- there is no workaround, because we (the users) are too stupid to understand it.

- nobody wants to share the syntax of the win api call. i have been fumbling around with that function for a few days and i gave it up. the params are too complicated, and i know quite a lot about vk keys and scan codes. maybe search a delphi or vb forum will help.

- so we have to wait for mercy.

i am very concerned about the way this problem has been treated in the other thread. the users who politely point it out and try to describe and fix it, are titulated as "stupid hotkey fanatics", and the bug is been negated. the correct way would be to say "thank you for the hint, we will fix it." of course i see that u.s. keyboard user do not notice this bug but it is somewhat insane and bad behaviour to negate it though. we all want to improve and support this wonderful scripting language.

negating the bug itself, at least it is a bug that the help file refers in a wrong way to the "send" command.

j.

and i wanted to say thank you for fixing this.

Edited December 26, 2007 by jennico

[schilbiz]

well,

we've been discussing that problem in the other thread. the essence is:

- will be fixed in next beta.

- there is no workaround, because we (the users) are too stupid to understand it.

- nobody wants to share the syntax of the win api call. i have been fumbling around with that function for a few days and i gave it up. the params are too complicated, and i know quite a lot about vk keys and scan codes. maybe search a delphi or vb forum will help.

- so we have to wait for mercy.

i am very concerned about the way this problem has been treated in the other thread. the users who politely point it out and try to describe and fix it, are titulated as "stupid hotkey fanatics", and the bug is been negated. the correct way would be to say "thank you for the hint, we will fix it." of course i see that u.s. keyboard user do not notice this bug but it is somewhat insane and bad behaviour to negate it though. we all want to improve and support this wonderful scripting language.

negating the bug itself, at least it is a bug that the help file refers in a wrong way to the "send" command.

j.

and i wanted to say thank you for fixing this.

I have been out of it for the last couple weeks due to the holidays but am back and still looking into this matter.

@ Jennico: What thread are you talking about? If you would, please tell me the name or link to it.

@ ako673de: I have gotten shift "+" to disable, but you have to put it with another key combination. The tough ones are ctrl and alt. You can usually disable the "windows key" within the keyboard settings.

HotKeySet("+","nothing") ; doesn't change anything
HotKeySet("a","nothing") ; a is disabled
HotKeySet("+a","nothing") ;A is disabled (shift+a)
While 1

Sleep(100)
Wend

Func nothing()
EndFunc

Would someone explain to me why Shift can not be disabled, but Shift+A can?

[ako673de]

@ ako673de: I have gotten shift "+" to disable, but you have to put it with another key combination. The tough ones are ctrl and alt. You can usually disable the "windows key" within the keyboard settings.

Fact is that all modifier keys can't be addressed as characters in HotKeySet. The notation as described in the Send command ("{+}","{!}","{^}","{#}") simply does not work with HotKeySet!

This bug (I repeat it is one!) becomes critical, if a not working character is the PRIMARY function of a key. If it is just a SECONDARY function then you can address it via a SHIFT/CTRL/ALT+(working!)key combination (e.g. on an english keyboard you can address the "plus" by using "+2" (=SHIFT+2, because here the "plus" sign is a SECONDARY function of "2", which is addressable).

But most probably you know that by now. New is that the bug obviously has not been addressed in the latest BETA v3.2.11.1! Any comments on this?!?

[PsaltyDS]

Fact is that all modifier keys can't be addressed as characters in HotKeySet. The notation as described in the Send command ("{+}","{!}","{^}","{#}") simply does not work with HotKeySet!

This bug (I repeat it is one!) becomes critical, if a not working character is the PRIMARY function of a key. If it is just a SECONDARY function then you can address it via a SHIFT/CTRL/ALT+(working!)key combination (e.g. on an english keyboard you can address the "plus" by using "+2" (=SHIFT+2, because here the "plus" sign is a SECONDARY function of "2", which is addressable).

But most probably you know that by now. New is that the bug obviously has not been addressed in the latest BETA v3.2.11.1! Any comments on this?!?

What bug? What key are you trying to HotKeySet() a function for, and can't?

[ako673de]

What bug? What key are you trying to HotKeySet() a function for, and can't?

There are many more or less good explanations out there in this forum, but I know that all this mess with characters, keys and so is a bit puzzling. Ok, one more try, hopefully now clear for everyone reading it:

The characters "+","!","^" and "#" (the modifier characters as described with the Send command) can't be HotKeySet-ted directly. The bracket notation workaround described with the Send command ("{+}","{!}","{^}","{#}") simply does not work with HotKeySet (although it should! Look at the help page of HotKeySet - first line in the "Parameters" box: The text in bold can't be misunderstood, I think)!

For example try

HotKeySet("{+}","function")

func function()
     consolewrite("x")
endfunc

and you will see an x on the console each time you press "SHIFT" and "=" (which is the "+" on an english keyboard!).

Here on my german keyboard however the "+" is located left of the return key and no modifier is needed for it. So without working bracket notation I'm stuck...

This thread is not the only one about this topic. Most of the others have been locked by some admin with the final comment that the issue will be (was!) fixed with the next BETA of AutoIt which should have been 3.2.11.0. I tried yesterday but found out that obviously nothing happened...