Re: NULL elements resolved
Re: NULL elements resolved
- Subject: Re: NULL elements resolved
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 22 Nov 2002 17:28:11 -0500
on 02-11-22 1:44 PM, Mike Engber at email@hidden wrote:
>
> It has finally dawned on me that I am receiving NULL affected elements
>
> in
>
> response to the AXUIElementDestroyed notification because -- well, the
>
> element was destroyed.
>
>
Your callback should never be receiving NULL for the UI Element ref. If
>
you are, it's a bug. I tried reproducing this (closing a TextEdit window
>
with a visible ruler) and none of the 3 destroyed notifications that
>
fired
>
got NULL.
>
Are you sure you're library isn't creating the NULL - perhaps passing
>
the UI ELement to some call and ignoring a kAXErrorInvalidUIElement?
Well, that's exactly what I'm saying. We're just coming at it from different
perspectives. As you'll see in a minute, you're Schroedinger's cat inside
the box, and I'm Schroedinger, sitting outside wondering whether you're dead
or alive.
To be perfectly precise: I put this code right at the top of my callback
function, and then close TextEdit's window while observing the application
for the kAXUIElementDestroyedNotification notification:
CFTypeRef value;
AXError error = AXUIElementCopyAttributeValue(affectedElement,
kAXRoleAttribute, &value);
NSLog(@"value=%@, err=%d", value, error);
The log says:
2002-11-22 16:34:16.753 Accessibility Browser[7108] value=(null), err=-25202
-- the error is kAXErrorInvalidUIElement.
As the documentation says, I'm not supposed to call any of the API functions
-- such as AXUIElementCopyAttributeValue -- on the element returned to the
callback function in response to the kAXUIElementDestroyedNotification,
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.
I guess what you're going to say is that the NULL value wasn't put there by
the callback function, nor by the AXUIElementCopyAttributeValue function,
but is instead just the NULL value that was there in the local variable in
the first place because of the empty initialization. In other words, I'm not
measuring what's in the element parameter to the callback function, but only
what I put in the 'value' variable -- namely, nothing.
Is that right? If so, I view this as a semantic issue, and I'm guilty as
usual of speaking loosely. The only way I know to test the UIElement
returned in the callback function is to look at it, and that yields NULL --
and an error that warns me I shouldn't believe what I see.
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. 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.
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. For you, the error already
exists, and it doesn't make any sense for me to ask whether you're dead or
alive because it isn't legal to look inside the box. For me, I know you're
either dead or alive because I'm a common-sense kind of guy, but I can't
know which until I look inside the box, which requires me to try to do
something that will turn out to be illegal -- or to have been illegal all
along, only I didn't know it yet.
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.
Now, you're a C programmer, and you also work for Apple and know what lies
inside a Core Foundation opaque type -- Schroedinger's box. I'm just a Cocoa
programmer, and I don't know anything about things like that.
What DOES lie inside that non-NULL but invalid element, anyway?
OK, that's enough fun for one day!
--
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.