From: Tim Oppmann on
I'm interested, but I don't have much experience in this area.
From: Karl E. Peterson on
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
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
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
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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Unicode Labels
Next: EM_CHARFROMPOS in RichEdit