Sendkeys, Appactivate and inconsitency
Andy
Ok, here is the deal. I've written a web page that has an input
form with as many as 30-40 variables. Hitting submit starts a
VBScript. So I start out the script and I focus on the main app
first, then I focus on the window that is being used in the app, then
I send a command to open a text box in that Window, then I send the
text contained in the variables (As well as some additional text) to
that text box. The problem being that this does not work
consistently. Sometimes None of the variables I am sending make it to
the text box, sometimes half of them make it to the text box,
sometimes all. I posted a bit of the script so you can have the
general idea behind it. I am having no problems with validating
variables, etc.....just getting them to send.
Would I be better off creating a single variable by continuing to
concantinate it every time an individual variable is validated? Or is
there a better way?
dim objShell
Set ObjShell = CreateObject ("Wscript.shell")
objShell.AppActivate("Main App")
objShell.AppActivate("Sub Window")
objShell.SendKeys "+{F6}" (Opens Text Box)
objshell.AppActivate ("TextBox")
if not document.Inputform.strfw.value = "" then
objShell.Sendkeys ("STRFW: " & document.Inputform.strfw.value &
chr(10))
end if
if not document.Inputform.strHeaderHeight.value = "" then
objShell.Sendkeys ("HeaderHEIGHT: " &
document.Inputform.strHeaderHeight.value & chr(10))
end if
if not document.Inputform.strTransHeight.value = "" then
objShell.Sendkeys ("TransHeight: " &
document.Inputform.strTransHeight.value & chr(10))
end if
Thanks,
Andy
Pegasus (MVP)
"Andy" <andy.l...@gmail.com> wrote in message
news:2d083d11-b105-40fa...@i7g2000prf.googlegroups.com...
>
> Ok, here is the deal. I've written a web page that has an input
> form with as many as 30-40 variables. Hitting submit starts a
> VBScript. So I start out the script and I focus on the main app
> first, then I focus on the window that is being used in the app, then
> I send a command to open a text box in that Window, then I send the
> text contained in the variables (As well as some additional text) to
> that text box. The problem being that this does not work
> consistently. Sometimes None of the variables I am sending make it to
> the text box, sometimes half of them make it to the text box,
> sometimes all. I posted a bit of the script so you can have the
> general idea behind it. I am having no problems with validating
> variables, etc.....just getting them to send.
>
> Would I be better off creating a single variable by continuing to
> validated? Or is there a better way?
>
> dim objShell
>
> Set ObjShell = CreateObject ("Wscript.shell")
>
> objShell.AppActivate("Main App")
>
>
> objShell.AppActivate("Sub Window")
>
> objShell.SendKeys "+{F6}" (Opens Text Box)
>
>
> objshell.AppActivate ("TextBox")
>
>
> if not document.Inputform.strfw.value = "" then
> objShell.Sendkeys ("STRFW: " & document.Inputform.strfw.value &
> chr(10))
> end if
>
> if not document.Inputform.strHeaderHeight.value = "" then
> objShell.Sendkeys ("HeaderHEIGHT: " &
> document.Inputform.strHeaderHeight.value & chr(10))
> end if
>
> if not document.Inputform.strTransHeight.value = "" then
> objShell.Sendkeys ("TransHeight: " &
> document.Inputform.strTransHeight.value & chr(10))
> end if
>
> Thanks,
>
> Andy
Macro programs are by their very nature fragile. They
depend on the right window being active at the right
time and the focus being on the correct part of this
window. Lots of things can upset this routine, e.g. a
virus scanner update popping up unexpectedly. In your
case, in view of the inconsistent behaviour, I suspect
that you're sending your keystrokes too soon. Insert
some sleep(x) commands before your send your keystrokes,
with x=1000 or so.
Andy
> "Andy" <andy.lisow...@gmail.com> wrote in message
I was under the impression that sleep doesn't work in web page design
and only on stand alone scripts.....I believe I read that somewhere
and had some problems with it. Would it simply be....
Dim x
x = 1000
sleep(x)
????
ThatsIT.net.au
you did say that you start a vbscipt
A agree with Pegasus, doing what your doing will only work when all goes
right, and user input at the wrong time or any other app taking focus will
crash your script, using sleep will help you send keys at the right time but
will increase the time the script takes to run and increase the chance of
something else interfering with it.
I don't know what your trying to do but I would look for a different
solution
Joe Fawcett
"ThatsIT.net.au" <me@thatsit> wrote in message
news:A5868531-20AB-4FA7...@microsoft.com...
Agreed, assuming you have to read the values client-side then try using the
Shell.Application's Windows function to get a collection of Explorer
windows. Iterate through until you find one that matches the location of the
one you want. Then you can use the document property to retrieve the form's
fields.
--
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
mr_unreliable
using Appactivate and SendKeys is an invitation to anxiety,
frustration, despair and ultimately failure.
Back in the days before IM and AV popups (telling you to go
get the latest rule set) and various other system activity
out of your control, appactivate and sendkeys may have worked
reliably enough. In the current environment we live in, you
can expect unreliable results.
The problem is that sendkeys acts like the system keyboard,
and sends keystrokes to the "active" (has system focus) app.
As has already been said, you may attempt to set your app
as active, but then something can happen to steal the focus
away.
There are other problems. Even on the newer very fast
processors with very fast hard drives, apps may take a while
to load. And also, apps sometimes have a "mind-of-their-own"
and only respond (if at all) when they get around to it, or
when some other "processor hog" gives up the processor so
your app can have a go. So there are other reasons for the
appactivate/sendkeys approach to fail, even if no IM's or
other popups crop up. Your keystrokes will go to some other
app, either to be ignored -- or worse, to cause some
irreparable damage.
The only way to really get what you want is to use the system
api. (O.K. all you professional sysAdmins, stifle your groans).
The reason for this is when using the system api, you deal with
the app and its controls via their system "handles". And so
when you send a message to a textbox (a.k.a. and "edit" control)
then that message is sent only to the handle (window or control)
you specify, and not to whatever window currently has focus.
Calling the system api is verboten from script. To get around
this limitation you have two choices. You can use a third-party
control (like DynaWrap) which allows for calling api's from script.
Or, you can use some other scripting language which DOES allow for
calling the system api (there are several: AutoIt and FBSL for two).
cheers, jw
____________________________________________________________
You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)
--- <DynaWrap Boilerplate> ---
It is possible to declare-and-call an api from script,
but you must use a third-party control to do so,
or else write one yourself.
It has already been correctly pointed out that there
is no api-capability in "pure" script.
If you are willing to use a third-party control, then
one such control, called "DynaWrap", can be found on
Guenter Born's website (note: Guenter refers to it as
"DynaCall"). Here is the link to it:
http://people.freenet.de/gborn/WSHBazaar/WSHDynaCall.htm
- or -
http://ourworld.compuserve.com/homepages/Guenter_Born/WSHBazaar/WSHDynaCall.htm
On that page you will find a download for the control,
plus some code samples.
Note: you may find additional sample code by searching
the archives of the wsh and vbscript ng's.
Note also: DynaWrap does have its limitations. There are
certain things it can't do. For example, you can't call
api's "by ordinal". (I had previously asserted that you
can't use DynaWrap to call api's which take typedefs as
parameters, but I have been proven wrong on that --
although it took me about two weeks to figure out how it
was done). Regardless, Dynawrap will work for most of
"the usual suspects".
And finally, DynaWrap doesn't work entirely as advertised.
For example, it is supposed to allow for the declaration of
several api definitions in one instance of itself. I could
never get that to work (in win9x -- but others have shown
this to work as advertised under winNT). With win98, you
will need a new instance of DynaWrap for every api, or else
re-instantiate the object for every api. Someday I'm going
to learn enough c++ to fix that...
--- </DynaWrap Boilerplate> ---