Re: Philosophy behind UI Element Destroyed notifications
Re: Philosophy behind UI Element Destroyed notifications
- Subject: Re: Philosophy behind UI Element Destroyed notifications
- From: Mike Engber <email@hidden>
- Date: Mon, 21 Jun 2004 11:03:45 -0700
What is the heuristic that developers are expected to follow?
Specifically,
should we generally "pretend" that a child element of a destroyed
parent
element is destroyed, even though the child element does not issue a
destruction notice? If that is the rule of thumb, will there be some
documentation to keep us all on the same path? For example, I can
easily
enough mark child elements of a "destroyed" drawer as destroyed, but
should
I do this with sheets, too?
In general, we don't treat being obscured as being destroyed.
As a rule, when a ui element is destroyed you must treat all its
descendants as being destroyed. If you don't then you may end up with
your refs suddenly going bad, or worse yet, pointing to entirely
different ui elements.
Sheets are just dialogs that are attached to windows. When they
disappears
and reappears they often come back in a different configurations (e.g.
the
open/save panel). This is why we treat window closing as destruction. At
the framework level that's about all we can do. Since the app knows
more,
I guess it could override this when appropriate - if we provided them a
way to do so - which we don't.
I'll grant you that drawers are a bit less clear cut - and the way
they're
commonly used more closely matches a model of obscuration. If we changed
to treating drawers this way it would mean a window would have to
report its closed drawers as children and expose the contents of those
drawer to accessibility. This would be problematic, maybe not
insurmountable,
but it would have to be investigated.
Anyway, if you feel strongly about either of these case you can file
bugs. But the general rule of a ui element being destroyed implying its
children are destroyed still holds.
-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.