Re: AXUIElementPostKeyboardEvent experience
Re: AXUIElementPostKeyboardEvent experience
- Subject: Re: AXUIElementPostKeyboardEvent experience
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 17 Dec 2002 05:27:35 -0500
on 02-12-16 9:49 PM, John O. Louch at email@hidden wrote:
>
> Another issue that I have found is that it has seemed best to NEVER
>
> supply the character code (supply zero) - only the virtual key code.
>
> I don't understand why though.
>
>
>
Yes never supply an character code, I think it says something like that in
>
CGRemoteOperation.h (could be wrong). Basically carbon takes that virtual
>
key code and then maps it to the correct character on the app side. There
>
is a technote which describes all the virtual key codes. I am trying to
>
find it for you (give me a day or so), but it is basically the Saratoga USB
>
layout.
As I mentioned in my reply to Andrew Taylor, supplying the charCode for
"real" characters seems to work correctly. The CGRemoteOperation.h header
example only uses 0 for modifier keys, supplying a non-zero charCode for
printable characters.
I've been puzzled as to why this function apparently wants both the charCode
and the keyCode. This is consistent with the data structures used by various
system-level functions, which always contain both the charCode and the
keyCode. My assumption is that the charCode is sometimes used as a hint for
those rare cases (according to IM Text) where the keyCode is not completely
hardware-independent. If I recall the IM passage correctly, there may be
some keyboards where some key presses do not uniquely identify the intended
character mapping, and a hint would be needed in such a case. This is
presumably not true of any U.S. Keyboards, or maybe not even for any Roman
language keyboards. Perhaps it relates to the JIS keyboard (Japan), which
led to the introduction of key remapping resources in Mac OS 8. If my
assumption is correct, it would not be necessary to supply the charCode for
U.S. or perhaps any Roman users, because the system would always "guess"
correctly based on the current active keyboard resources. But if you wanted
your app to work correctly for Japanese or perhaps other non-Roman users you
would have to make provision for the charCode as well as the keyCode.
I did encounter crashing when I inadvertently supplied a charCode that was
inconsistent with the keyCode I supplied (but another bug I found in my code
at the same time could have accounted for that).
I found the recent TN2056 on "Installable Keyboard Layouts" under Jaguar
<
http://developer.apple.com/technotes/tn2002/tn2056.html>, but it deals with
the next step in key translation above the virtual key codes we're talking
about. I haven't found the one you're talking about.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.