Re: Accessibility overrides leads to leaks?
Re: Accessibility overrides leads to leaks?
- Subject: Re: Accessibility overrides leads to leaks?
- From: Christiaan Hofman <email@hidden>
- Date: Mon, 13 Sep 2010 23:32:18 +0200
On Sep 13, 2010, at 21:05, James Dempsey wrote:
>
> On Sep 11, 2010, at 4:10 AM, Christiaan Hofman wrote:
>
>> I have a problem where setting an accessibility override seems to lead to a leak. hat I'm doing is taken from the AXCanvas sample code, in particular -[CanvasDocBorderView awakeFromNib], i.e. using accessibilitySetOverrideValue: to set the parent (window) for an extra view added to a scroll view. This is necessary because there does not seem to be any other way to make such a view accessible. But what I see is that the window isn't deallocated after it's closed, which means that accessibilitySetOverrideValue: creates a retain loop and therefore a leak. Is this a known problem? And is there a way to fix this?
>
> -accessibilitySetOverrideValue:forAttribute: retains the value object that is set. You can set the override value to nil when the window closes by listening to notification.
>
> It is not advised, though, to set overridden values for attributes such as AXRole, AXParent, AXChildren - but only for attributes such as AXDescription, AXHelp, AXTitleUIElement.
>
This is directly copied from the sample code I mentioned.
> This is because calling -accessibilityAttributeNames: does not take the overridden attribute into account - so any internal accessibility code asking for these fundamental attributes will get the wrong value.
>
This makes no sense to me. The names don't change (every accessible element has a parent). And why would the internal code do something different? If it does not get the overridden value, than that internal code would be wrong, or the whole idea of overriding is buggy by design.
> The best practice for changing the value of attributes such as AXRole, AXParent, AXChildren is to return the different value in a subclass.
>
> -James
>
It's not even clear from the POV if the object itself which object should be its parent in this case. This really is an implementation detail of the parent view (or window in my case). That's also why it's the parent view's (window's) code that sets the override value. This is also responsible to consistently add the object as a child.
Christiaan
> --------------------------------------------------
> James Dempsey
> AppKit Engineering
> Apple
> email@hidden
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden