Re: Archiving or copying observers and elements
Re: Archiving or copying observers and elements
- Subject: Re: Archiving or copying observers and elements
- From: Mike Engber <email@hidden>
- Date: Thu, 12 Dec 2002 17:33:19 -0800
On Thursday, December 12, 2002, at 04:01 PM, Raymond Fischer wrote:
You betcha. I've an app which is responding to accessibility
events and doesn't register for notifications. Is that a
target app?
I sounds like it is a target app.
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?
It should be no problem to create them on the fly.
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.
I was answering from the point of view of an assistive app, but that
doesn't
make much difference - the key point is that these refs are being
passed between different processes.
Think about it this way.
You return an array of AXUIElementRefs representing the children. This
array is sent to another process (the assistive app, e.g. a screen
reader) - since the assistive app is in a different address space it
must have a copy of your array and all the AXUIElementRefs in it.
Next, the assistive app sends you back one of these AXUIElement refs in
a attribue value request. By the same reasoning you must receive a copy
of it.
Now, I guess if someone was caching every AXUIElementRef going back and
forth they could match this second generation copy back to the original
- but that would require keeping the original (i.e. every
AXUIElementRef) in memory indefinitely.
I'm just now realizing the confusion being caused by the fact that
Carbon uses AXUIElementRefs in its accessorization API (i.e. what
target apps have to do to work with the Accessibility API). A Cocoa
developer would never ask this question because as a target app he
hands out only NSObjects and requests are processed by sending messages
to these objects.
-ME
_______________________________________________
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.