Re: Archiving or copying observers and elements
Re: Archiving or copying observers and elements
- Subject: Re: Archiving or copying observers and elements
- From: Raymond Fischer <email@hidden>
- Date: Thu, 12 Dec 2002 16:01:50 -0800
On Thursday, December 12, 2002, at 02:56 PM, Mike Engber wrote:
I think you're confusing the assistive app vs target app.
You betcha. I've an app which is responding to accessibility
events and doesn't register for notifications. Is that a
target app?
Besides, isn't copying an AXUIElementRef just a matter of getting the
HIObject and ID and putting them into a new AXUIElementRef? Am I
missing something?
I can assure that an AXUIElementRef referring to an element in a Cocoa
app does not contain an HIObject and ID.
"Cocoa"? What's that?
(Sorry. Bad humor. As cool as Cocoa is I have not had the chance to
spend
much time looking at it, much less using it.)
AXUIElementRefs are opaque and are primarily an assistive app concept.
On the target app side - you do end up providing _things_ that have to
be returned, via accessibility, as AXUIElementRefs. In Carbon this is
done very directly using AXUIElementCreateWithHIObjectAndIdentifier.
In Cocoa you hand
off an NSObject and we take over from there - you never actually deal
with
AXUIElementRefs themselves.
This brings to mind an interesting point. Even though in the Carbon
world
you have fns like AXUIElementGetHIObject which allow you to pick apart
an
AXUIElementRef - those are only for use by target applications - code
that
makes your app accessibile.
You should not be using them in assistive apps. If you get an
AXUIElementRef
that's not from Carbon, these calls will return garbage or crash.
So it's basically a box where I can store stuff that's useful to me.
Since the box can move and since what's in the box is what's important
to me anyway, I don't look at the AXUIElementRef itself. I assume that
the pointer is just a means to get at what's in the box.
In my early attempts with accessibility I would assume that when I
created
an AXUIElementRef and put it into an event, that same AXUIElementRef
would
have the same pointer value when I got it back later. Turned out to be
a bad
assumption, and I went for a different approach that turned out to be
better
anyway.
But since we're on the subject, is it bad to create a new
AXUIElementRefs
all the time? It's been easier to CFRelease and create anew than to
save
the ref somewhere. I assume that that's not a serious performance
problem.
Is that a correct assumption?
While I'm no expert with Mac accessibility (is anyone?) I've found
that
caching AXUIElementRefs to be less than useful. It has been bad to
assume that an application will always give you the same
AXUIElementRef
for a given HIObject. The app may just create a new one each time.
Since you (the assistive app) do not share the same address space with
your target app you never really get "the object" that the target app
is
handing out. Whether or not the target app is creating a new object on
every request doesn't matter - you're always getting a newly allocated
copy in your own address space.
Even when I create the AXUIElementRef and get it back in another event?
Such as when I return the children for a UI element and then am asked
for the children of one of the children.
However, all AXUIElementRefs for a given user interface element should
be CFEqual (just not pointer equal). So, I don't understand your
comment
about caching AXUIElementRefs to be less than useful.
But I was doing pointer equal and that doesn't work, as you point out.
Your explanation has been helpful. Thanks.
----
Ray Fischer
Adobe Systems
_______________________________________________
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.