Re: Top-10 Accessibility API Wish List
Re: Top-10 Accessibility API Wish List
- Subject: Re: Top-10 Accessibility API Wish List
- From: Guy Fullerton <email@hidden>
- Date: Wed, 11 Sep 2002 13:51:53 -0700
On 9/11/02 5:49 AM, "Andrew Taylor" <email@hidden> wrote:
>
We maintain information regarding the contents of windows until the
>
window is actually closed. Typically this is dictated text and the
>
supporting audio and speech recognition information.
>
When a window is hidden, instead of issuing a window hiddent event, a
>
kAXUIElementDestroyedNotification is issued, causing us to throw away
>
all our data structures in the expectation that the window is gone.
>
If the window is subsequently shown again, all dictation information
>
is not available. We don't need to access the window while it is
>
hidden.
Hidden windows are (in the vast majority of cases) *gone* as far as the user
is concerned. Because accessibility notifications are intended to reflect
what the *user* sees, we send Destroyed notifications when windows are
hidden. We also (intend to) send Created notifications when a hidden window
is shown.
Unfortunately, some applications hide their windows transiently while they
do other manipulations to them (like move or resize). Generally, such
behaviors are a holdover from Mac OS 9, and are no longer necessary on Mac
OS X. If you find applications that still do this kind of thing, the app
developer should be contacted so they know to change their behavior.
If you are talking about some other situation where windows are hidden,
please let me know.
With the current set of APIs on Carbon and Cocoa, we have no way of knowing
whether a hide action signifies destruction or a transient hide. We
therefore must assume every hide signifies destruction.
_______________________________________________
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.