Re: AXUIElementPostKeyboardEvent experience
Re: AXUIElementPostKeyboardEvent experience
- Subject: Re: AXUIElementPostKeyboardEvent experience
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 17 Dec 2002 05:33:48 -0500
on 02-12-16 9:36 PM, Andrew Taylor at email@hidden wrote:
>
Sending a command key to a background application means you are
>
controlling the application when it is in a disabled mode and it is
>
not expecting the user interface to be sending events to it. This
>
should not be something you do because the target application may
>
crash or exhibit other bad behavior as a result of receiving
>
unexpected events. I believe this is why the suggestion that you use
>
the menu item and post the press action. That way I suspect that the
>
menu code will have the opportunity to determine that it is not
>
active and therefore not operate. Are you even able to find an
>
inactive menu item?
Yes, the accessibility API lets me browse all the menus and submenus of
every target application, even while they're in the background -- as long as
I start at the root and work toward the leafs. There are a few limitations
to performing menu item commands while the target app is in the background,
along the lines you suggest. For example, some (all?) menus can't see their
parent (although the parent can see the child), and performing menu commands
requires that some (but not all) apps be activated first. The latter is
presumably the same, or similar, issue that I encountered when trying to
send a Command-key equivalent to a background menu item.
>
There is yet another issue here, international keyboards. The virtual
>
keycodes are different depending upon the active keyboard. Dvorak has
>
its own keycode map as well.
I don't think you have that quite right. I re-read the relevant parts of
"Inside Macintosh-Text" last night and was reminded that there are three
steps to key translation: (1) individual keyboards generate so-called "raw"
codes that do indeed differ from model to model. (2) The system has a driver
for every known keyboard, which maintains a table (KMAP, at least in the old
days) that translates every raw key from every known keyboard to a standard,
hardware independent "virtual key code". (3) The script system translates
the virtual key code to a glyph or glyphs, depending on your language
preferences and the installed script system (using the Keyboard menu, if
you've turned it on in System Preferences). IM Text describes the "virtual
key code" as "hardware independent," while the Cocoa documentation for
NSEvent's keyCode method describes it as "hardware dependent." This
disparity threw me off for a while, but now I think they're just coming at
the same thing from opposite directions.
>
The sample code "iGetKeys" provides a way for you to reverse engineer
>
a virtual keycode table depending upon the active keyboard.
I found iGetKeys. Thanks for the reference. It looks interesting, although I
now understand that I should never have to translate in that direction. I
found a simple utility called KeyCode that lets me see the standard,
hardware-independent "virtual key code" for any key on my keyboard, just by
pressing a key, and that should be enough.
>
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.
I don't think that's necessary. The sample in the CGRemoteOperation.h header
uses 0 for the character code only for modifier keys, but it uses a real
character 'Z' cast to type CGCharCode for printable characters. I've got it
working that way in my Cocoa assistive application. I call the characters
method in Cocoa's NSEvent class to get the NSString in the current keyboard
event after the user types a key into my utility app, then pass it to the
keyChar parameter of AXUIElementPostKeyboardEvent like this:
(CGCharCode)[characters characterAtIndex:0].
As I said in a separate message this morning, I believe the keyChar
parameter is not necessary for U.S. or possibly any Roman keyboard, but you
probably do need to use it for Japanese and perhaps other non-Roman
keyboards to provide required hints to assist key translation on that
hardware.
--
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.