Re: Archiving or copying observers and elements
Re: Archiving or copying observers and elements
- Subject: Re: Archiving or copying observers and elements
- From: Bill Cheeseman <email@hidden>
- Date: Thu, 12 Dec 2002 11:47:12 -0500
on 02-12-12 9:36 AM, John O. Louch at email@hidden wrote:
>
You can only retain the AXObserverRef and AXUIElementRef objects. What do
>
you mean by archiving? You cannot store an AXUIElementRef from an app
>
beyond the lifetime of that app/element. I.e. If you quit the application
>
that the AXUIElement references then the element will become invalid.
>
>
Can you give me an example on why you need a copy primitive?
1. You're correct that the AXObserverRef and AXUIElementRef objects can't be
used to communicate with the target application or the UIElement after the
target application or the UIElement is gone. But the reference might still
be useful for my assistive application's management of its internal data
structures. For example, the reference could be used with CFEqual to clean
out any cached references I still have hanging around after a UIElement is
destroyed. (Mike Engber explained that possibility to me recently.) In the
process of designing such a system, it might prove useful on occasion to
make a copy of the reference instead of just CFRetaining it again, depending
on what I'm doing and how I'm handling memory management.
2. "Archiving" is a Cocoa technology (isn't there something like it in
Carbon?) that allows me to cache "freeze dried" representations of dynamic
data structures, such that they can later be unarchived into a live state
that is fully functional. It's useful not just for saving dynamic data
structures to disk (which wouldn't be much use in the accessibility
context), but also for sending distributed objects to other running
processes. It might be useful in the accessibility context to give another
process the ability to carry out some of the operations that would normally
be carried out by the assistive app directly. Perhaps using multiple
threads, for example.
In general, in Cocoa there are several commonly used operations that require
you to mark your classes as conforming to the NSCoding or NSCopying
protocols. But you can't easily do this if one of your class's important
instance variables can't be copied or encoded. Since AXObserverRef and
AXUIElementRef are opaque data types, Apple is the only person who can
implement the ability to copy them. As I understand it, many Core Foundation
opaque data types currently implement shallow copying with "CreateCopy"
functions, and will in the future implement deep copying. It seems to me
that the accessibility API should do this as well, in the interest of giving
developers greater flexibility in how they design assistive apps. I wouldn't
expect it to be hard to do, but you guys know a lot more than I do about how
complicated your internal data structures might be.
3. The particular problem I face is how to work around the bug in the
accessibility API which makes it impossible to unregister notification
observers. I was surprised at how many repercussions this bug has, and how
hard it is to work around all of them. Because of this bug, I currently have
to maintain a cache of all observers and mark those that are "virtually"
unregistered. I have to maintain this cache in order to prevent my callback
function from doing its thing when it is called on a virtually unregistered
but actually registered notification. It would have been easier to develop
this workaround if I could have encoded the virtually unregistered observers
in an archive, to keep them from issuing notifications to my callback
function, then unarchive them back into live condition if my code
re-registers them while the target application is still active. But I've
found another way to handle the issue in the meantime, basically killing the
observer when appropriate, then creating a new one when needed.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.