Re: AXUIElementPostKeyboardEvent experience
Re: AXUIElementPostKeyboardEvent experience
- Subject: Re: AXUIElementPostKeyboardEvent experience
- From: "John O. Louch" <email@hidden>
- Date: Mon, 16 Dec 2002 18:49:41 -0800
>
At 8:25 PM -0500 12/16/02, Bill Cheeseman wrote:
>
> on 02-12-16 6:27 PM, John O. Louch at email@hidden wrote:
>
>
>
>> It sounds like you are using the wrong api in any case. If you want an app
>
>> to quit, then send it a quit appleevent. If you want to do a menu command
>
>> when the app is in the background then find the menu item with the
>
>> Accessibility api and post the AXPressAction.
>
>
>
> I'm surprised by your answer, because AXUIElementPostKeyboardEvent is part
>
> of the accessibility API. This leads me back to my original question: what
>
> is the intended purpose of the AXUIElementPostKeyboardEvent function? If
>
> it's just to put text in a text view or text field, why isn't setting the
>
> text attribute enough? The problem with the AXPressAction is that it often
>
> requires the "background" app to be brought to the front in order to work. I
>
> thought sending a Command key equivalent via AXUIElementPostKeyboardEvent
>
> might be a good workaround for that. I'm a little confused by all this.
>
>
>
>
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?
>
>
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.
>
The sample code "iGetKeys" provides a way for you to reverse engineer
>
a virtual keycode table depending upon the active keyboard.
>
>
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.
Thanks,
jl
>
_______________________________________________
>
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.
---------------------------------------------
John Louch Internet #: email@hidden
(805) 546 0216
_______________________________________________
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.