Re: ToAsciiEx/LoadKeyboardLayout question

From: Alex (sdfjkhsdkh_at_ksfjdkjwdfsklj.nowhere)
Date: 08/02/04 

Date: Mon, 02 Aug 2004 10:31:33 -0400

"Michael \(michka\) Kaplan [MS]" <michkap@online.microsoft.com>
wrote in news:OoifG5tdEHA.3732@TK2MSFTNGP11.phx.gbl:

> "Alex" <sdfjkhsdkh@ksfjdkjwdfsklj.nowhere> wrote...
>
>> I've encountered somewhat interesting problem in non-english
>> windows.
>
> It seems to me that this problem can just as easily happen by
> installing any of the hundreds of possible keyboards on a US
> English system as running on non-english Windows....
Yeah, I just meant that the problem is bad when the user doesn't
want to have US English keyboard in his list.
>
>> The origin of the problem is that keyboard wedge devices send the
>> data by emulating "key presses" wisely assuming that the keyboard
>> layout is US English. When the current keyboard layout is
>> different, it doesn't work so well.
>
> Perhaps the solution is to find "keyboard wedge devices" that do
> not make this inappropriate and often incorrect assumption?
Do they exist? And can they exist? First problem is that I suppose it
is impossible to retrieve current keyboard layout through the PS/2
keyboard interface. Another problem is what if the user's current
keyboard doesn't have characters that need to be transmitted?
 
>> To retrieve these data properly I have to
>> pass the input through ToAsciiEx with the HKL from
>> LoadKeyboardLayout for US English.
>
> Just curious -- why would you not use ToUnicodeEx here? Since most
> of those non-English keyboards will contain entries off of the
> default system code page....
All input characters are ASCII (because of the standards on the
incoming data), would ToUnicodeEx and ToAsciiEx be any different?
 
>> That's fine when the user has US English in the list
>> of his inputi methods on his computer. If he doesn't,
>> LoadKeyboardLayout adds US English to the list of input methods
>> (which probably is not nice to the user).
>
> Yes, this can be confusing. Though I have found (in implementing
> MSKLC's "Load From Existing..." functionality) that a "load the
> layout, get every piece of info about the layout, unload the
> layout is a very fast operation. It works quite well in MSKLC, and
> it actually handles all of the extreme cases like SGCAPS and Dead
> Keys and such....
>
>> If there's nothing I can do
>> about it, I would like to remove it from the list at the end of
>> the program. I can get layout list before calling
>> LoadKeyboardLayout to remember if it was in the user's list or
>> not, but I need to have this logic in more than one application
>> which causes even more complications.
>
> See above -- its actually very fast. The easiest way to do it:
>
> 1) GetKeyboardLayoutList to get the currently loaded list in a
> nice array 2) LoadKeyboardLayout on your keyboard layout
> 3) Check to see if the HKL returned by #2 is in the list returned
> by #1 4) Do whatever you need to do
> 5) If the answer to #3 is YES then unload the layout when you are
> done
>
> Like I said, it works quite well, and quite quickly, in MSKLC.
That was my idea, but it raises few questions which the docs doesn't
seem to answer (see below)
>
>> After studying MSDN help on those functions I can't say I
>> understand what they're doing exactly.
>
> Not sure I know what you mean here....
For example:
- Application A loads keyboard layout, which is not in the current
list.
- Application B fetches current keyboard list (will it get the layout
just loaded by application A or not?)

And:
- Application A loads keyboard layout, which is not in the current
list.
- The user presses keyboard layout switch key
- Application A unloads keyboard layout

What will happen in this case?

After observing different behaviour on different OS I'm a bit scared
of establishing it by experiments and I'd prefer to find info on what
is actually being done.
>
>> Interestingly, test
>> application doesn't behave the same way on Windows NT and XP. On
>> NT, if I unload previously loaded layout, another application
>> that has loaded the same layout can keep using it, but on XP it
>> can not.
>
> Well, the cases there have more to do with situations where the
> unload was delayed to "on reboot" due to it being in use that were
> fixed up so that no wait was required.
Help states that UnloadKeyboardLayout will fail if:
- The input locale identifier was preloaded.
- The input locale identifier is in use.
What means "preloaded"? And what means "in use" (shall it be active
to be "in use"? or it is enough for some application to have handle
to this layout?)
>
>> What I'm really looking for is to call ToAsciiEx(...,"eng_US")
>> which would be transparent for the user, but I can't find any
>> functions which would allow to do it.
>
> There really are none in the Win32 API... though I have yet to
> ever see the extra keyboard entry in MSKLC, which follows the
> steps 1-5 given above. And it works for any and all keyboard
> layouts.
>
>> As a last resort, I can hardcode content
>> of the US english layout into the application and do translation
>> myself, but this method looks somewhat ugly.
>
> Yes. That of course get me back to the original points about the
> APO choice and the use of apps that make such a silly mistake
> about keyboard choices?
>:-)
Another problem here is that even keyboard wedge device is using
other than US English layout (which I think is unlikely), there's no
reason to think that it will be compatible with any layout used in
Windows.

What I don't like about the situation, that all keyboard layout
manipulations interfere with the layout list selected by the user,
while the conversion itself is not something that the user should be
concerned about and I'd prefer it to not affect the user in any way.

I wonder if there're any standards on keyboard layouts and
maybe some code+data can be obtained from such a standard
organization which would allow conversion without interfering with
the user's lists.

Thanks in advance,
Alex.

Relevant Pages

  • Re: RosAsm?[OT#2]
    ... >> accent marks on some of the word ommitted because of ASCII and UK ... because it has the keyboard layout as a nice little ASCII ... _ONE ADDITION_ that is not on the keyboard diagram but I ... that many UK typists simply "get used" to typing with a UK keyboard ...
    (alt.lang.asm)
  • ToAsciiEx/LoadKeyboardLayout question
    ... I've encountered somewhat interesting problem in non-english windows. ... The origin of the problem is that keyboard wedge devices send the ... layout is US English. ... When the current keyboard layout is different, ...
    (microsoft.public.vc.language)
  • Re: ToAsciiEx/LoadKeyboardLayout question
    ... > want to have US English keyboard in his list. ... I would ask whether a user truly switches their layout with the ... We have tested extensively with MSKLC and never seen a problem. ... > the user's lists. ...
    (microsoft.public.vc.language)
  • Re: Umlaut
    ... >> an american keyboard, just changing the layout doesn't help. ... >> write in German and my wife occasionaly writes in Spanish. ... English laptop. ...
    (alt.os.linux.suse)
  • Re: Keyboard registry question
    ... The value is probably there because you have Canadian English for a keyboard ... HKEY_CURRENT_USER\Keyboard Layout ... This subkey ...
    (microsoft.public.windowsxp.setup_deployment)
Loading