Re: Clarification on the AXFocusedWindowChanged notification
Re: Clarification on the AXFocusedWindowChanged notification
- Subject: Re: Clarification on the AXFocusedWindowChanged notification
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 06 May 2016 12:28:14 -0400
On May 6, 2016, at 11:25 AM, David Burgun < email@hidden> wrote:
I was wondering how the AXFocusedWindowChanged Notification works. When one is received does this mean that the Window is getting Focus or losing Focus or both?
If there are two windows A and B and A has focus and the user clicks into B, should this send a AXFocusedWindowChanged both A and B, or just B?
From the Yosemite NSAccessibility formal protocol reference document: "This notification is posted after the key window changes." This suggests to me that you should be observing the application element, not a specific window element.
When I register to observe the Finder for this notification in UI Browser, the notification log reports that the "affected element" is the window that gained focus.
The AXFocusedUIElementChanged Notification is presumably similar, except that it reports the specific UI element within the window that gained focus. The formal protocol reference document is a little clearer, saying "This notification is posted after an accessibility element gains focus."
This is all consistent with the fact that you cannot use the accessibility API to set a UI element's focus to false. You can only set it to true. Only one element in an application can have focus at a time, and reporting the element that gained focus is more useful than reporting the element that lost focus. |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden