I opened "C:\WINNT\system32\wshom.ocx" file (where
WScript.Shell object is implemented) with OLE/COM Object
Viewer and I can see that WshShell.SendKeys method has
signature:
void SendKeys(
[in] BSTR Keys,
[in, optional] VARIANT* Wait);
Does anybody know anything about second "Wait" parameter?
How can it be used?
Thanks in advance
Alex
While this page applies to (classic) vb6:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vastmsendkeys.asp
It is probably what ms had in mind for the wait parameter
in wsh also (even though un-advertised), as vbs was patterned
after vb.
cheers, jw
____________________________________________________________
You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)
Thanks. It looks very promising. I hope that
WshShell.SendKeys has similar semantics. It's interesting
how can they ensure that "keystrokes are processed".
Supposedly SendKeys uses SendInput. So, I can't see how it
can be ensured without internal knowledge of target
application. However, if SendMessage is used, then it might
work.
Anyway, thanks for information. I'll give it a try.
For one, take a look at the "SendMessageCallback" api.
You could use it to send a wm_char message, and then
get a "callback" (i.e., a notification) when the message
was processed.
I have never used the "wait" parameter of sendkeys, but
it does seem that it could be useful. What I normally do
is send a keystroke and then wait-a-bit using the "sleep"
method of wscript. As everybody knows, different apps
process keystrokes at different rates. If you send keys
"too fast", for example by sending long strings rather than
a key-at-a-time, you run the risk of losing some of the
keystrokes. And so, rather than play around with "sleep"
delays as I have done, wouldn't it be better to just wait
until the keystroke was accepted, and than go about your
business?
cheers, jw
____________________________________________________________
You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)
Yes, I know about SendMessageXXX family API. However, I'm
writing script, not native program. So, natutrally, I can't
use API functions.
> I have never used the "wait" parameter of sendkeys, but
> it does seem that it could be useful. What I normally do
> is send a keystroke and then wait-a-bit using the "sleep"
> method of wscript.
That's what I'm doing, too. My problem is that I'm writing
HTA, not regular WSH script. So, I don't have WScript.Sleep
method. Currently I'm sleeping with quite ugly piece of
code, which is out of scope of this post. It works and
that's all I need. However, if SendKeys can provide me with
"cleaner" wait, then I'd prefer it to my waiting function.
> As everybody knows, different apps
> process keystrokes at different rates. If you send keys
> "too fast", for example by sending long strings rather
> than a key-at-a-time, you run the risk of losing some of
> the
> keystrokes. And so, rather than play around with "sleep"
> delays as I have done, wouldn't it be better to just wait
> until the keystroke was accepted, and than go about your
> business?
I'd be happy to wait for key processing in more robust way.
However, there is no way to know it outside of target
application. It can do anything on keypress and you'll never
know. The best bet is to wait enough time after each
keystroke so target application can be on pace with your
script.
Actually, VB6 documentation refers it as boolean type, not
mumeric type. It should just delay keypresses, but "wait
until keystroke is processed", whatever it could mean.
> Also in the 'official' docu, the wait-param isn't
> mentioned and sample-scripts use WSH.Sleep instead.
> Probably MS initially designed the method with an
> optional delay and then simply didn't implement it,
> not removing the param from the signature.
Yes, that's what I'm afraid of. It would be nice to hear
some confirmation from MS people.
> If you want a robust Sleep method available for HTA or
> other non-WSH-Hosts, you could simply wrap the
Kernel32-Sleep
> into a small ActiveX-DLL.
I considered writing ActiveX control, however my goal is to
stay withing script as much as possible for various reasons.
I peeked at AutoItX, too. Currently, I'm not using it for
the same reason. I think when annoyances will reach some
critical mass, then I'll write ActiveX finally.
Thanks
Alex
A sample script is attached.
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
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 for this ng, and the vbscript ng.
Note also: DynaWrap does have its limitations. There are
certain things it can't do. For example, you can't call
api's which take typedefs as parameters, and you can't call
api's "by ordinal". But it 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). 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> ---
Thanks for the answer. I already explained to Christoph
Basedau that my goal is to keep the script really lean and
mean. So, I'm trying to avoid writing native code right now,
not to speak of third party controls.
Thanks anyway
Alex