Re: Archiving or copying observers and elements
Re: Archiving or copying observers and elements
- Subject: Re: Archiving or copying observers and elements
- From: "John O. Louch" <email@hidden>
- Date: Thu, 12 Dec 2002 09:34:11 -0800
>
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.
Ok, please right a bug to have a copy primitive added to AXUIElementRef. I
am not sure if is possible for the AXObserverRef.
>
>
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.
I assume you are creating a daemon process which allows you to talk to
application through the AX api from remote machines, or other users. There
is not way to flatten an AXUIElementRef outside of the API. You could
create another feature request bug, but this is not a small task for us to
accomplish. The actual code is not to hard, but once you have established a
format then you have to support it forever. I.e. Do not count on it in the
short term.
>
>
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.
Guy or Mike will have to comment but I believe the crashing bug on
un-registering was fixed in a Software Update. Note: killing the observer
should cause the same crash, as it un-registers all handlers. I don't see
any reason why you would want to archive here, and not just keep a bunch of
references around in some data structure.
Thanks,
jl
>
>
--
>
>
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.
---------------------------------------------
John Louch Internet #: email@hidden
(805) 546 0216
_______________________________________________
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.