Quote:
> Can you please explain why. I had inferred that you were
> sending WM_CHAR messages without sending corresponding
> WM_KEYDOWN, WM_KEYUP etc. messages. I hacked Petzold's
> keyview1.c to show otherwise.
You cannot do it this way because you are breaking the rules. Every
application can expect to get messages using the sequence defined by the
system. If you are sending only WM_CHAR messages to a specific
application, it may work. But it doesn't work in any case. So it's not a
suitable way for a generic method like SendKeys.
Quote:
> I was surprised to find that those messages you send do
> not set a scan code in HIWORD(lParam). My deficient
> understanding is that such messages do not comply with
> the interface.
Sending scan codes is conceptually a bad idea although it doesn't cause
problems. Look at the MSDN doc which describs the keyboard model on the
first pages. Scan codes are device dependent (although on a standard PC
they are all the same which is forced by special hardware, the 8042
chip). But Windows is not PC: I'm writing this using a Unix keyboard
(funnily with 22 function keys - no typo, 22, not 24). Virtual key codes
are needed to introduce device independency. System calls translating
keycodes like ToUnicode() typically ignore scan codes as long as a
virtual key code is present. It doesn't matter whether you are setting
the scan code, too.
Quote:
> Am I write in thinking that sendkeys is not
> internationalised. e.g. it is of little use in driving
> applications where accented letters are needed. (I have
> no ability to produce such letters as it has not been
> considered necessary for users of British keyboards)
There is no such thing as an international keyboard. The whole story is
completely independent from internationalization. That's done by a layer
above the virtual keycodes: the keyboard layout (see p.e. Win32 API
LoadKeyboardLayout). That's ok because there may be different layouts on
the same keyboard. I guess you do not use it, but most developers in
Germany have both english and german layout installed - you can switch
between two layouts by a hotkey. On the german keyboards, the key
labeled "Z" is "Y" using the english layout and vice versa, all other
letters are the same. (BTW: The layout switches the char code a n d
the virtual key code - "Z" is "Z", regardless what is printed on the
keycaps.) Umlaute on a german keyboard are found on some dedicated keys.
Other european characters are buld by keystroke sequences like pressing
"^" followed by pressing "a" which creates the french accented letter
"a".
Quote:
> I would value an explanation for not supporting
> "Print Screen". I am not terribly surprised as -
> on this machine - it only produces a WM_KEYUP message.
That's a point I can't understand, too. Implementing the "Print Screen"
with SendKeys is simple, and I don't see any reason why it wasn't done.
(If you ignore the "gourmet problem" - so we call problems like this -
how to get a hardcopy and to be sure the caret is not in the bitmap.)
Quote:
> As documented, no distinction is made between the
> two variants of the following: ARROWS, digits, DEL
> or DELETE, END, ENTER, HOME, INS or INSERT, PAGE
> DOWN, PAGE UP and possibly others!
That's an old story. The keys you've mentioned are called extended keys
because the were introduced with IBM's extended keyboard for the XT
(which is "extended technology" - if anything is not extended, it is
advanced, or (NT!) new). To distinguish the new keys from the old, IBM
decided to set a marker on the new keys. So the new ENTER key on the
keypad was able to get the same code as the old ENTER key. The marker is
a prefix byte, 0xE0 (224), which is send by the keyboard processor
directly before the scan code. Since the first version of Windows,
Microsoft translates the presence of an extended key prefix to bit 24 of
the lParam of the WM_KEYDOWN, WM_CHAR, and WM_KEYUP messages. You may
set it but I do not know about any system component nor about any
application which interprets it.
Because you've cried loud for it, I've build it into my WScriptEx object
for which I'll send the next version out tomorrow so you may write
process.SendKeys("{Extd ENTER}"). But I think there's no use for it. For
the Extd modifier, not for the rest of WScriptEx ;-)
Quote:
> I read that as "It is old code we have not visited for
> a while and would prefer to forget"
That's not fair. Mike's point is: It doesn't matter whether the code is
good or bad, it's there, and people know how to use it. And it's much
cheaper to build on an existing code base than to do a complete rework.
Even if you decide to do a complete rework it's difficult to design a
better interface while retaining those parts which are proven to work
well (integrate mouse actions into the keystroke sequence, blocking the
user while sending, finding reliable replacements for AppActivate, ...).
And it's also a matter of time. As noted above: I've reimplemented it. I
estimated it needs about 100 hours - for a single method! That's far
more than any other part of WScriptEx.
And to Mike:
Quote:
> As for the "lack of documentation" - I consider
> this pseudo-documented. The docs don't indicate
> a way to do it because there isn't a way to do it.
> We don't document everything that our products
> don't do, and if you think about it, we can't -
> there are too many things you might want to try.
> We try to point out some of the more obvious ones,
> like SendKeys not handling "Print Screen", or the
> fact that you can't use it for applications not
> designed to run under Windows.
Until today I thought the doc is unacceptable but now I feel converted,
you've done the job: That's no real doc, it's a pseudo-doc ;-)
And, btw, there are docs like the Win32 doc which do not point out what
doesn't work. Instead they clearly point out what's going on so you get
the feeling what you can't do. Using the WSH doc, I'm happy about any
remarks what doesn't work because it helps understanding what's going
on. It's the weakest part around the product today.
Greetings from Zrich Uwe
SendKeys method and keypad