SendInput and Unicode
in [Visual Basic]
|
Prev: Unicode Labels
Next: EM_CHARFROMPOS in RichEdit
From: Tim Oppmann on 30 Jan 2009 19:14 I'm interested, but I don't have much experience in this area.
From: Karl E. Peterson on 2 Feb 2009 20:13 expvb wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote ... >> I wonder if it really matters from a SendKeys perspective, though? I >> mean, if you sent a "�" to Sendkeys, it'd just use whatever codepage was >> in effect, no? Shouldn't a drop-in SendKeys replacement do the same thing? >> (Semi-rhetorical, granted.) >> >> I guess I need to read those pages you cited. Thinking ahead, are you >> suggesting I possibly just slip the test down to do the unicode processing >> for anything >= 128? > > You can always consider anything < 256 to be ANSI, which what VB's SendKeys > does. If someone wants to send Unicode characters in the range 128 to 255, > then they can change the source code by themselves. Very good point. :-) And the very goal of that project was to replace/replicate SendKeys. >>> It seems that in order to get keyboard scan codes, keyboard >>> layout and support for specific code pages has to be loaded(In the >>> Control >>> Panel perhaps), so it doesn't seem possible to get scan codes for every >>> possible Unicode char. You can however send a Unicode char by sending >>> WM_CHAR using the W version of SendMessage after checking that the window >>> is a Unicode window by calling IsWindowUnicode(). >> >> Not sure I'm following there? > > I was saying that it's not always possible to get scan codes for every > character. After checking the documentation, when you use KEYEVENTF_UNICODE, > Windows sends VK_PACKET, which later translates to WM_CHAR and converted to > ANSI if the window is ANSI, so there is nothing special you need to do. > However, it seems that in certain situations the Unicode character is > discarded. Use the Search tab in MSDN and type "VK_PACKET" (5 results), or > "IME_PROP_ACCEPT_WIDE_VKEY" flag, which affect how VK_PACKET is processed. Okay, will take a look. >> Would be wise to add something like that, but I think it'd just fail >> silently (except on Win95) without it, right? > > You can call VB's SendKeys in Windows 9x. Heh, there's a snarky workaround, alright! <bg> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 2 Feb 2009 20:16 Thorsten Albers wrote: > Karl E. Peterson <karl(a)mvps.org> schrieb ... >> I wonder if it really matters from a SendKeys perspective, though? I mean, if >> you >> sent a "�" to Sendkeys, it'd just use whatever codepage was in effect, no? >> Shouldn't a drop-in SendKeys replacement do the same thing? (Semi-rhetorical, >> granted.) > > I wouldn't bother about codepage issues: You are providing an ANSI and a > Unicode version of your procedure. The ANSI procedures always sends ANSI > characters, the Unicode procedure always sends Unicode characters (even for > 0-255). It's up to the developer which of the two procedures he has to > call. Hmmmm, that's not what that code was doing, though. Rather, it was just processing the passed string, one character at a time, and then stuffing a SendInput buffer based on what was found. If the character was >=256, it would stuff it with a Unicode character. If it was 0-255, it'd use the normal ANSI procedures, taking into account things like Shift states and such. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 2 Feb 2009 20:18 mark.tunnard.jackson(a)googlemail.com wrote: > I agree with Thorsten. And I don't think checking AscW<255 is going to > work anyway. For instance, on code page 1252 (English & Western > Europe), ANSI character 0x83 is Unicode character 0x0192 ("#LATIN > SMALL LETTER F WITH HOOK") > > ? ascw(chr$(&H83&)), asc(chr$(&H83&)) > 402 131 > > Unicode character 0x0083 is a non-breaking hyphen. > > The point is that "ANSI" character code 128-255 will map to a > different set of Unicode characters depending on the code page. I'm > not sure how best to test whether a character is supported on the > current code page. Maybe convert Unicode->"ANSI"->Unicode and see if > the string is unchanged? Yikes! That's getting real ugly real fast. Another thought would be to offer a new escape character, much like VB provides escapes for the three common shift keys? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 2 Feb 2009 20:21
Thorsten Albers wrote: > Karl E. Peterson <karl(a)mvps.org> schrieb... >> 1) Is a simple 0-255 check sufficient recognition for "Unicode" characters, where >> the input variable 'this' is a single character from a longer string? > > Yes, unless you want to deal with codepage pecularities since Unicode > character codes 128 to 255 encode always the same characters while ANSI > character code 128 to 255 are codepage dependent. What's scary is Mark's example: ? ascw(chr$(&H83&)), asc(chr$(&H83&)) 402 131 I guess it'll still work, though? I mean, so I get 402 instead of 131, all that means is I'm ignoring the Shift escapes and pushing a Unicode character into the buffer, eh? >> If code >= 0 And code < 256 Then 'ascii > > Easier and presumably faster: > If Not CBool(code And &HFF00) Then Was gonna make sure the test was valid first, of course. He said. Heh... <g> Yep! >> 3) What else I've overlooked? <g> > > Maybe you should check for some Unicode characters and prevent them from > beeing sent, like the > > - High surrogates > D800h to DBFFh > - Low surrogates > DC00h to DFFFh > - Specials > FFF0h to FFFFh > > It can't be excluded that sending one of these to a process may cause > trouble... First I've ever heard of them! Remember, I'm USian, and therefore *highly* unicode-impaired. :-/ -- ..NET: It's About Trust! http://vfred.mvps.org |