Reconsidering AXUIElementPostKeyboardEvent
Reconsidering AXUIElementPostKeyboardEvent
- Subject: Reconsidering AXUIElementPostKeyboardEvent
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 17 Dec 2002 17:21:06 -0500
For the reasons described below, I submit that AXUIElementPostKeyboardEvent
fails to execute correctly with an application-specific root element.
It malfunctions both when the specified target application is in the
background AND when it is frontmost, and it malfunctions with ALL modifier
keys, not just the Command key. Whether the target application is background
or frontmost, no modifier keys are sent but the naked character is sent.
This behavior is inconsistent, and it is contrary to the preliminary
documentation.
The function works correctly with a system-wide element, sending both the
character and all specified modifier keys.
Detailed analysis follows:
Further testing this afternoon discloses that I initially misstated the
issue. I had thought that a background app wasn't responding to a
Command-key combination that I had hoped would trigger a menu item command.
It turns out, however, that my testing -- which was focused on remote
control -- was too narrow. In fact, no modifier keys are even getting
through to the target app. Instead, the naked key gets through, but all
modifiers are ignored. In other words, the issue is not one of controlling a
background app, but instead one of modifier keys not being transmitted.
I found this out by trying to type a capitalized letter into TextEdit,
initially with TextEdit in the background. I sent the Shift-key down event
first, then the letter key down, and then each back up in reverse order. But
the letter kept appearing in the background TextEdit window in lower case. I
couldn't find any error in my code, and debugging confirmed that the
statement sending the shift key down event was in the execution path.
I finally tried executing the same code using the system-wide element,
bringing TextEdit to the front first. This time, the letter appeared
capitalized in the TextEdit window. The same test with the Option key down
yielded the same result -- when using an application-specific element and
targeting it as a background app, TextEdit doesn't see the Option key, but
when using the system-wide element, it does.
The final logical step in my testing, therefore, was to try the
application-specific element again, but this time bringing TextEdit to the
front. By golly, TextEdit did NOT see the Shift key or the Option key even
though it was frontmost.
So this isn't an issue of Command-key equivalents in menu items, at all. It
appears instead that the modifier keys simply aren't getting through when
using AXUIElementPostKeyboardEvent with an application-specific element --
whether or not the target application is frontmost -- but they are getting
through when using it with a system-wide element. That is, the issue is one
of the function not working correctly with an application-specific element,
without regard to whether the target application is frontmost and without
regard to which modifier key is used.
So, Eric's and others' insistence that background apps aren't supposed to
respond to Command-key equivalents is beside the point. The behavior of the
function with application-specific elements is incorrect with ANY MODIFIER
KEY, and WHETHER OR HOT THE TARGET APP IS FRONTMOST.
Also, the behavior is flatly contrary to the preliminary documentation for
AXUIElementPostKeyboardEvent, which says "Posts keys to the specified
application. This is similar to CGPostKeyboardEvent(), but it allows you to
specify the target application as opposed to always sending them to the
active application. See CGRemoteOperation.h for details. If the system-wide
element is passed as the application argument, the event is sent to the
active application."
This implies, as I read it, that sending the event to an
application-specific UIElement is supposed to work EVEN IF THAT APPLICATION
IS NOT "THE ACTIVE APPLICATION." But, even if it is read some other way, it
clearly states that the event will work when sent to an application-specific
element that is frontmost. But it doesn't work.
Comments?
--
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.