SendKeys Method when Computer is Locked
koalabear123
will not work when the computer is locked? This is a very annoying
limitation, and a registry fix for this issue is badly needed. My guess is
that there is probably an undocumented registry hack to prevent this from
happening, but Microsoft has perhaps not publicized it for security reasons.
From a practicality standpoint, disabling SendKeys when the computer is
locked makes sense for most systems. Very few people require programs to run
when they aren't at the computer, and clearly there is ample opportunity for
exploit of this method if allowed to run when the computer is in a locked
state.
However, most programmers use this method to automate server processes,
especially GUI based processes that have no command line interface. In these
cases, not being able to use SendKeys when the computer is locked is a
horrible limitation. It forces the sysadmin to turn off the "Lock Computer"
function completely in the registry in order to have the SendKeys method
persist for a scheduled task. This has the effect of actually compromising
security on the system in question by making it completely vulnerable to
physical attack.
Microsoft...please, please, please address this issue. Sendkeys is used for
process automation. Process automation, almost by definition, is for when you
aren't at your computer. When you aren't at your computer, you want to lock
it to prevent physical access. Thus, SendKeys needs to be able to function
when the computer is locked.
Pegasus (MVP)
"koalabear123" <koalab...@discussions.microsoft.com> wrote in message
news:06F7EBC6-6A37-4C21...@microsoft.com...
I'm a little surprised to hear you praise the SendKeys method and berate its
lack of availability when the computer is locked. In my experience SendKeys
is a kludge that should be used only when everything else fails. It should
not be used in robust applications because of its inherent lack of
reliability. Several things can and will upset it at any time. Here are just
three of them:
- The expected prompt takes much longer than expected to pop up, perhaps due
to some other task such as an automatic update consuming a lot of CPU time.
- The application behaves differently than usual for some unexpected reason.
Humans can respond to it appropriately. Macros can't.
- Some unexpected prompt pops up and needs to be dealt with, e.g. a virus
scanner update or a reboot request from an automatic update.
If this was my show then I would look for alternative ways to automate the
task.
koalabear123
life that there are windows programs that have no command line interface. For
these programs, SendKeys is the only option available for scripting windows
automation.
Sendkeys certainly isn't robust, but the fact of life is that there are
Windows applications that need Sendkeys for process automation. Unfortunate,
but true....
I agree with all of your criticisms of using Sendkeys. However, when working
with commercial programs, it is sometimes the only way to go for process
automation.
Pegasus (MVP)
Some Windows applications, e.g. Word or Excel, have VB Script objects that
make macros superfluous. BTW, I suppose you're aware that a "Koala" is about
as related to a "Bear" as a camel is to a horse. If they were related then
bears would raise their offspring in a pouch.
mr_unreliable
> Does anyone know how to work around the limitation in Windows where SendKeys
> will not work when the computer is locked?
hey koalabear,
afaik, you are out of luck. I don't know what "locked" means,
but if you are talking about the normal keyboard and mouse "lock"
then sendkeys just plain won't work -- because sendkeys is using
the same mechanism as the keyboard (keybd_event api), and so
sendkeys gets locked out just like the keyboard.
If you want to "do-it-right", then you have to take another
approach, which unfortunately involves using the system api.
What you do is use the FindWindow or FindWindowEx api to get
the "handle" of the parent window of your app, and then the
"handle" of the child window you are interested in. Then
(sometimes) you will need to use "SetFocus" to get the focus
rectangle on the child window (because some apps won't respond
unless the control has focus, others don't care). And finally,
you use SendMessage to send the control a system message, to
do what you want. For example, if the control of interest is
a button, then you would send it a "BM_CLICK' message. And
finally, you have to be willing to "play around" to get the
app to respond. For example, a microsoft button will probably
respond to a bm_click message, but some apps coded in other
languages will make up their own buttons. In that case, you
should try positioning your mouse over the button (there are
other api's for this) and sending a mouse down, followed by
a mouse up.
This approach was suggested and developed by Dino Esposito in
his Visual Studio Magazine article in the May 2002 issue,
entitled: "Add Object Models to Non-COM Apps" ... I tried to
look up a reference to this, but I'm afraid that VSM has
flushed it away. They apparently think that any 2002 tech
is no longer useful or valid.
There is an even more sophisticated approach, suggested by
Igor Ladnik in a Code Project Article entitled: "Automating
Windows Applications" (and should be subtitled automating
windows applications THAT DON'T HAVE AN AUTOMATION INTERFACE).
http://www.codeproject.com/KB/COM/automatingwindowsapps.aspx
Igor suggests the risky approach of "injecting" a custom dll
into the address space of your app, and letting the dll do the
"dirty work".
Personally I prefer the system api approach. It is difficult
but not impossible to call api's from vbScript -- you have to
use a 3rd-party control. Or, use another scripting language
that allows for calling system api's as part of the language
(there are several).
cheers, jw
____________________________________________________________
You got questions? WE GOT ANSWERS!!! ..(but, no guarantee
the answers will be applicable to the questions)
mr_unreliable
> This approach was suggested and developed by Dino Esposito in
> his Visual Studio Magazine article in the May 2002 issue,
> entitled: "Add Object Models to Non-COM Apps" ... I tried to
> look up a reference to this, but I'm afraid that VSM has
> flushed it away. They apparently think that any 2002 tech
> is no longer useful or valid.
>
Visual Studio may have flushed away Dino's work, but "xiaotaoliang"
has preserved it here (in English!):
http://www.cnblogs.com/xiaotaoliang/archive/2005/03/03/112306.html
Unfortunately, xiaotaoliang didn't preserve Dino's code. He/she
only referenced the visual studio code, which is now gone. If
somebody is really serious about this, I may be able to find it
but that will involve searching many old "dusty" cd's.
cheers, jw
Al Dunbar
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
news:OoH59atM...@TK2MSFTNGP02.phx.gbl...
>
> "koalabear123" <koalab...@discussions.microsoft.com> wrote in message
> news:06F7EBC6-6A37-4C21...@microsoft.com...
<snip>
> I'm a little surprised to hear you praise the SendKeys method and berate
> its lack of availability when the computer is locked. In my experience
> SendKeys is a kludge that should be used only when everything else fails.
> It should not be used in robust applications because of its inherent lack
> of reliability.
In fact, it cannot be used in robust applications because adding that kind
of thing to a robust application removes its robustness ;-)
> Several things can and will upset it at any time. Here are just three
> of them:
>
> - The expected prompt takes much longer than expected to pop up, perhaps
> due to some other task such as an automatic update consuming a lot of CPU
> time.
> - The application behaves differently than usual for some unexpected
> reason. Humans can respond to it appropriately. Macros can't.
> - Some unexpected prompt pops up and needs to be dealt with, e.g. a virus
> scanner update or a reboot request from an automatic update.
It's bad enough watching a sendkeys scripts go off the rails. I'd shudder to
think what might be going on when a system is locked.
mr_unreliable gave a really studious explanation based on the fact that,
even if sendkeys could function on a locked computer, they could not do
anything because,being locked, the system is not processing keyboard input.
I'd look at it the other way and wonder what on-screen objects the sent keys
could possibly be interacting with.
/Al