Home > Archive > Delphi > March 2004 > Disabling certain keys in system globally
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Disabling certain keys in system globally
|
|
| mikes 2004-03-27, 12:21 am |
| Hi everyone!
I need to disable ceratain key strokes and key stroke combinations
(Esc key, Alt+F4) for other applications. My experience in Delphi
programming is rather narrow, so this problem is a bit beyond my
current capabilities. I'm supervising some free-access PCs, and some
apps running on them must simply be on continuous run. I don't want
any jokers to turn them off by any Alt+f4 comobos or rebooting the
system in whole. So the only solution to this is disabling the certain
keys for the whole system. How can I do the described above? Code
examples would be a big BIG help
thanks and regards to all my gurus ;)
mikes
| |
| Rob Kennedy 2004-03-27, 12:21 am |
| mikes wrote:
> I need to disable ceratain key strokes and key stroke combinations
> (Esc key, Alt+F4) for other applications. My experience in Delphi
> programming is rather narrow, so this problem is a bit beyond my
> current capabilities. I'm supervising some free-access PCs, and some
> apps running on them must simply be on continuous run.
Then they should be services. You can't terminate services very easily,
especially when they're running under different privileges from the
current user. The users should have user-level, not administrator-level,
privileges.
> I don't want
> any jokers to turn them off by any Alt+f4 comobos or rebooting the
> system in whole.
Rebooting shouldn't be a problem; just make sure the programs are
configured to start when Windows starts. Alt+F4 doesn't work on
services, but it's a common enough keystroke that users will get
 when it doesn't work to close Word or Internet Explorer.
> So the only solution to this is disabling the certain
> keys for the whole system.
No, there are other ways of locking down a public terminal, and they
don't generally require custom programming.
--
Rob
| |
| mikes 2004-03-27, 12:21 am |
| Rob, big thanks for your comments!
One of those apps needs to display some info on the desktop all the time.
Can it still be as a service? It also needs to run CONTINUOSLY, ergo,
reboots are not welcome, it also reguires some alphanumeric input sometimes
form the user...
As you can see it's not that simple...
what can I do?
regards, Mikes
Rob Kennedy <me3@privacy.net> wrote in message news:<c3n344$29u4tr$1@ID-220940.news.uni-berlin.de>...
> mikes wrote:
>
> Then they should be services. You can't terminate services very easily,
> especially when they're running under different privileges from the
> current user. The users should have user-level, not administrator-level,
> privileges.
>
>
> Rebooting shouldn't be a problem; just make sure the programs are
> configured to start when Windows starts. Alt+F4 doesn't work on
> services, but it's a common enough keystroke that users will get
> when it doesn't work to close Word or Internet Explorer.
>
>
> No, there are other ways of locking down a public terminal, and they
> don't generally require custom programming.
| |
| Jeremy Collins 2004-03-27, 12:21 am |
| mikes wrote:
> Rob, big thanks for your comments!
>
> One of those apps needs to display some info on the desktop all the time.
> Can it still be as a service? It also needs to run CONTINUOSLY, ergo,
> reboots are not welcome, it also reguires some alphanumeric input sometimes
> form the user...
If you're writing the application, then don't allow it
to close! Just trap Alt+F4 etc, and remove the system
menu. A more sophisticated approach is only allow the
app to close if the user is an Administrator. User account
settings can be used to prevent access to Task Manager
and disallow shutdown / logoff.
Other ideas:
I haven't done this myself, but maybe you could create an
ActiveX control and add it as an active desktop item...?
If it were just *one* application you could replace the
Explorer shell, but it sounds like you want multiple apps
to run.
--
jc
Remove the -not from email
| |
| David 2004-03-27, 12:21 am |
| Use a tool called dwinlock it works very well and cheap to buy.
David
"Jeremy Collins" <jd.collins@ntlworld-not.com> wrote in message
news:L9W7c.72$z_6.11@newsfe1-win...
> mikes wrote:
>
time.[color=darkred]
sometimes[color=darkred]
>
> If you're writing the application, then don't allow it
> to close! Just trap Alt+F4 etc, and remove the system
> menu. A more sophisticated approach is only allow the
> app to close if the user is an Administrator. User account
> settings can be used to prevent access to Task Manager
> and disallow shutdown / logoff.
>
> Other ideas:
>
> I haven't done this myself, but maybe you could create an
> ActiveX control and add it as an active desktop item...?
>
> If it were just *one* application you could replace the
> Explorer shell, but it sounds like you want multiple apps
> to run.
>
> --
> jc
>
> Remove the -not from email
| |
| Andrzej Szukiewicz 2004-03-27, 12:21 am |
| mikes is responsible for commiting following post
> Hi everyone!
>
> I need to disable ceratain key strokes and key stroke combinations
> (Esc key, Alt+F4) for other applications. My experience in Delphi
> programming is rather narrow, so this problem is a bit beyond my
> current capabilities. I'm supervising some free-access PCs, and some
> apps running on them must simply be on continuous run. I don't want
> any jokers to turn them off by any Alt+f4 comobos or rebooting the
> system in whole. So the only solution to this is disabling the certain
> keys for the whole system. How can I do the described above? Code
> examples would be a big BIG help
>
> thanks and regards to all my gurus ;)
> mikes
Try hooks. To be more specific, the WH_CBT hook.
<quote from MSPSDK>
WH_CBT Hook
The system calls a WH_CBT hook procedure before activating, creating,
destroying, minimizing, maximizing, moving, or sizing a window; before
completing a system command; before removing a mouse or keyboard event
from the system message queue; before setting the input focus; or before
synchronizing with the system message queue. The value the hook
procedure returns determines whether the system allows or prevents one
of these operations. The WH_CBT hook is intended primarily for
computer-based training (CBT) applications.
For more information, see the CBTProc function.
For information, see WinEvents.
</quote>
Greetz,
Andrzej Szukiewicz
|
|
|
|
|