Re: Unique ID for elements
Re: Unique ID for elements
- Subject: Re: Unique ID for elements
- From: Mike Engber <email@hidden>
- Date: Fri, 10 Nov 2006 09:25:10 -0800
On Nov 10, 2006, at 8:12 AM, Ian Archer wrote:
I want to maintain some state about UI elements that are accessed.
One problem I'm facing is that there does not seem to be a way to
refer to an element by some globally (or even application-specific)
ID.
The AXUIElementRef _is_ what "uniquely" identifies the ui element. I
put uniquely in quotes - more on that below.
You can use the AXUIElementRef as the key in a dictionary to map it
to whatever state info you want to keep.
You should register for notifications so you'll know when a ui
element is destroyed and you can evict it from the table.
You going to find that you can't successfully register for
notifications on some ui elements (at least this will be true for
Cocoa target apps). With luck, the problematic ui elements will be
ones you don't care about and you can either choose not to track
them. Otherwise, the best you can do is find an ancestor with which
you _can_ successfully register notifications, and then evict the
descendant when the ancestor is destroyed.
Someone is bound to ask. "Why exactly is it, that I can't register
for notifications on some ui elements in Cocoa apps?"
Here's the gist of the problem - all Cocoa specific info - all
subject to change.
The ui elements you can't register notifications are ones that Cocoa
can't uniquely associate an object with. For widgets like NSView's
there is a straightforward mapping of the NSView object to the the ui
element it represents. But, there are cases where this isn't so. E.g.
for a given table view column, all the rows share the same NSCell
object. E.g. for a slider, there is no NSObject that represents the
thumb.
These problem cases are handled by creating "relative"
AXUIElementRefs that keep track of a ui element relative to some
ancestor that does have a unique object associated with it. E.g.
conceptually, something like "the second child of the first child of
foo" (foo being an NSView). This is analogous to some constructs in
AppleScript. In practice, these chains are rarely deeper than one.
I.e. they'll usually just be "the nth child of foo."
AXUIElementRefs for relative ui elements are a bit problematic. If
you hold onto one, you'll never get a notification when it's
destroyed. If you use it after it has been destroyed then it may
reference some entirely different ui element. I.e. assuming the
ancestor foo is still around and has n children, "the nth child of
foo" refers to a valid ui element - just not the one you expect.
As I said above, the best you can do is assume that their lifetime is
tied to their ancestor chain and assume they're destroyed with their
ancestor. This generally works - but I'm sure there are plenty of
problem cases.
-ME
_______________________________________________
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