Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
- Subject: Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
- From: Matt Gough <email@hidden>
- Date: Wed, 26 Mar 2003 15:22:00 +0000
>
> So is there a solution to this that prevents this hanging?
>
>
My idea would be: keep a global NSTimer object around and release the
>
observers from the timer. When you get the WindowDestroyed
>
notification, if you haven't created the timer yet, create it and give
>
it a short delay; if you have created it already, reset the timer's
>
fire time to be the current time plus the delay. Hopefully that way the
>
timer won't fire until all of the notifications have been received, and
>
at that point, you can release all of the observers.
I went with a similar solution. My app (which is Carbon, not Cocoa) already
sends itself Null events via a Timer, so I just hooked it into that
processing.
I was thinking though, as long as I eventually CFRelease the observer
itself, do I still need to AXObserverRemoveNotification on each notification
it is interested in. i.e. will it still leak if I don't. Currently I have
one observer per application I am observing and when that app quits, the
observer is released. Surely this should clean everything up, and if it
doesn't wouldn't that be considered a bug?
Matt
_______________________________________________
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.