Re: NULL elements resolved
Re: NULL elements resolved
- Subject: Re: NULL elements resolved
- From: Mike Engber <email@hidden>
- Date: Fri, 22 Nov 2002 15:32:52 -0800
because the element isn't valid. So of course I get the
kAXErrorInvalidUIElement error when I do it anyway, which tells me
that I
should ignore the result. But in the meantime, there's a NULL value
sitting
right there in my value parameter.
Yes, a NULL value for, not a NULL UI Element. This is a BIG
distinction, the latter would be a bug.
If I put this code at the top of the callback method, instead, in
order to
avoid passing the returned element to an API function:
NSLog(@"element=%@", affectedElement);
I get this log:
2002-11-22 16:50:14.316 Accessibility Browser[7132]
element=<AXUIElement
0x214fcb0> {pid=1449}
And no error.
You will say this proves that the element returned in the callback
function
isn't NULL, because there's an address there, plain as day.
Exactly. It's NULL but invalid - as documented.
This is an example of Heisenberg's uncertainty principle at work. Or
Schroedinger's cat. The cat's dead; he just doesn't know it yet -- but
he's
also dead. You know there's something in that element; the only
trouble is,
when I try look at it, it goes away.
Not really, the act of looking doesn't _cause_ the error. This is more
akin to
a bad pointer - you know it's bad - don't dereference it. The pointer's
value/address might still be useful to you (see below) - just don't
dereference it.
Another way of describing our different perspectives is this. I can't
see
the error until I try to look at the returned element, using the only
tool
at my disposal, an API function. You already know the error will be
generated, so you say I shouldn't do that.
You already know too because it came from a destroy notification. If
you choose to ignore this, that's just putting on blinders.
In fact, you really can't safely choose to ignore this info. This is
important:
"There is no guarantee that passing an ref to a destroyed UIElement to
an Accessibility API will return kAXErrorInvalidUIElement."
Let me say that again:
"There is no guarantee that passing an ref to a destroyed UIElement to
an Accessibility API will return kAXErrorInvalidUIElement."
If we return to the bad pointer analogy. If you dereference a bad
pointer you still might get back an object. Possibly, a good object if
that memory has been reallocated - just not the object you expect.
I will say that
it might as well be NULL, because the only way I can check for an
error to
judge its validity is to call one of the API functions on it, but
that's
illegal and leaves me with a NULL value for my trouble.
For your purposes the invalid UI Element may not be useful, but that's
not necessarily the case for everyone.
E.g. someone might register for destroy
notifications on the app element so that all destroys are handled by the
same callback which proceeds to look through a large cache of UI
Elements
removing any that are CFEqual to the destroyed element.
In fact, this might be a useful thing for your library to do. If you
have wrapper objects for UI Elements, when a destroy comes in you could
go through an mark the appropriate wrappers as bad. The wrappers
various methods (e.g. getValue) could check if their bad before calling
into the AX APIs with the bad reference.
Taking into account what I said above ("There is no guarantee that
passing an ref to a destroyed UIElement to an Accessibility API will
return kAXErrorInvalidUIElement.") you pretty much have to do this (or
I guess you could have each wrapper individually register for the
destroy notification).
In any event, don't wait, for example, until you call
AXUIElementCopyAttributeValue to check if it returns
kAXErrorInvalidUIElement.
If you're about to post a message about a mysterious bug involving a
UIElement ref (perhaps a cell in a table view) suddenly pointing to
some other element - re-read this message.
-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.