On your last point, are you saying that tab order goes in reverse window tree order by default, i.e., up Z order as you tab? I'm sure it does not go the same direction - in other words, I have proven that if window A has window B as next window in the winAPI, by default window B may be reached by Shift+Tab from window A but not by Tab.
On Wed, Dec 15, 2010 at 08:57:08AM -0500, Ron Parker wrote: On 12/15/2010 8:43 AM, Doug Lee wrote: >Subject pretty much says it all: What order are the windows in the >Children and DirectChildren returned in? Possible orders I can think >of for DirectChildren would be Z order (same as with the WinAPI calls >for get next/previous window) and tab order. Children could be in >some sort of screen-based logical order, tab order, recursive Z order, >or depth-first or breadth-first tree order variants of those. Of >course, either could also be officially undefined, but I bet they're >not. > > Officially, yes, the order is undefined. Unofficially - which is to say, this is subject to change in any version, so if you count on it you should verify it for each new version of Window-Eyes - it's in reading order, left to right, top to bottom, by the upper left corners of the windows. As if that weren't useless enough, the "Children" tree is breadth-first, mainly because that turns out to be marginally easier to implement without recursion. (For breadth-first you just push the elements onto the back of a queue. For depth-first you have to push them onto a stack, but in reverse order. Whoever wrote this code - I think it was me - apparently didn't want to mess with enumerating them in reverse order for something that wasn't officially going to be documented anyway.) By the way, Z order and tab order are the same thing. Strange but true. -- Doug Lee, Senior Accessibility Programmer SSB BART Group - Accessibility-on-Demand mailto:[email protected] http://www.ssbbartgroup.com "While they were saying among themselves it cannot be done, it was done." --Helen Keller
