I could then use AXUIElementGetHIObject to get an HIObjectRef of
the object and finally check its type with IsValidControlHandle to
find out whether this is a control or not.
Did I miss something hence the above approach does not work for me?
Are you doing this from code inside the focused process, or from
another process? HIObjectRefs are only valid inside the owning
process. If that HIObjectRef goes to another process, it won't be
usable there.
I'm doing that from the same process.
I was receiving strange results from the mentioned approach so I've
decided to stick HIViewRef as a textual param instead.
kAXFocusedUIElementAttribute will return the element in the
application that has "keyboard focus", not "VO cursor focus".
By default, keyboard focus will follow the VO cursor (though the
user can turn this off in the VoiceOver Utility), but only when the
element that the VO cursor is on can receive keyboard focus. Not
all UI elements can receive keyboard focus (e.g. static text
elements).
So there is no guarantee that the keyboard focused element (given by
kAXFocusedUIElementAttribute) will be what the VO cursor is
currently focused on.
The window I accessorize consists entirely of my own HIViews so I
could go around the above limitation by supporting focus and that
should work reliably, shoudn't it?
There is no way to ask for the element that the VoiceOver cursor is
currently focused on.
I'm able to get the item under the cursor if the mouse cursor follows
the VO cursor but I still think that there should be a way how to
obtain an element under the VO cursor.
Tomas
--
# Ing. Tomas Zahradnicky, Jr.
# The Czech Technical University
# Dept of Computer Science, FEE-CTU Prague
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/accessibility-dev/email@hidden
