Re: AXUIElementDestroyed question
Re: AXUIElementDestroyed question
- Subject: Re: AXUIElementDestroyed question
- From: Mike Engber <email@hidden>
- Date: Mon, 17 Mar 2003 11:23:14 -0800
In my app I have just started observing AXUIElementDestroyed on my app
as a
whole as I want to know when windows get destroyed. What has surprised
me is
that my call-back proc only gets called for windows and not for other
UIElements which I assume must also exist within those windows (i.e.
controls etc)
I'm speaking for Cocoa apps here. Carbon may make the same
optimization, I'm not sure.
One thing to note (and I think this is documented) is that destroyed
notifications
are only sent for elements you have previously received a ref for.
Since the element is already destroyed, there is nothing you can do
with a ref to it
except compare it to other refs you're holding (e.g. to clear it out of
a cache).
So, if we've never supplied you with a ref to the element being
destroyed, there's
no point in sending out a destroyed notification.
Hopefully, that explains the lack of notifications you're seeing,
because I don't
know of cases of us failing to report destroyed notifications - apart
from the
limitation described below.
Now, you'll find that there are some ui elements that you can't
register for
notifications on. (again, this is Cocoa specific) Destroyed
notifications will
never be sent for these - even if you're holding a reference to them.
This is
due to limitations in the accessibility implementation. E.g. cells in a
table
view are particularly problematic.
-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.