Doug,
I just launched word as the document area is a custom control. I put
the mouse over the document window and brought up immed and typed:
print typename(mouse.window.control)
and I got "Control" as the result. Just to verify I then did:
print mouse.window.type
and got 11 which is custom control so this clearly isn't as simple as
all custom controls. If you have more specifics I'll be glad to check
it out.
Regards,
Doug
On 12/9/2010 11:25 AM, Doug Lee wrote:
Jon says he's seeing this issue on controls that WE calls custom
controls.
On Thu, Dec 09, 2010 at 10:14:08AM -0500, Ron Parker wrote:
I just looked at the code, and the only reason you should ever fail to
get a Control object for a window would be if the window itself isn't in
the Window-Eyes OSM for some reason. That should be fairly rare.
On 12/9/2010 10:04 AM, Doug Lee wrote:
Yes this is very helpful info. The only remaining concern I can see
is that my coworker, Jon, reports that not all windows have .control
objects associated with them.
On Thu, Dec 09, 2010 at 09:49:34AM -0500, Doug Geoffray wrote:
Then yes, the Window.Control.Previous and Window.Control.Next will get
you the previous and next window in Z order (also commonly referred to
as tab order). In fact when you use these properties, Window-Eyes
simply calls the GetWindow function with either GW_HWNDPREV or GW_HWNDNEXT.
You may also be able to use the Window.Control.Taborder property to also
help you...
Does this help?
Doug
On 12/9/2010 9:26 AM, Doug Lee wrote:
I don't know my coworker's exact use case, but one I can think of is
when a control in focus is predictably labeled by the control prior to
it in Z order, or the prior Static control in Z order, or less
commonly, by the prior Static to the focused control's parent or
grandparent. Screen readers sometimes automate this sort of tree
search because these algorithms have proven effective in enough cases
I guess. I've run into the need for this sort of thing quite often in
JAWS scripting, though off the top of my head I don't know how many of
those instances would have been adequately addressed by just a loop
through directChildren.
On Thu, Dec 09, 2010 at 08:32:22AM -0500, Doug Geoffray wrote:
Hello Doug L,
Regarding your Z order question... Can you give me a specific example
what you are needing this for? Maybe that would help us give you a
better idea of what you can currently do or something we could add in
the future.
Thanks,
Doug G
On 11/22/2010 3:33 PM, Doug Lee wrote:
We're looking for a reliable way to get the next and previous window
in Z order from a given window. It might sometimes also be useful
to get the first and last window in Z order at the given window's
tree level. The Windows API GetWindow() function allows this sort
of query, and there are WinAPI functions for next and prior window,
but I don't see a direct way to do it in Window-Eyes. I'm betting
I missed something obvious.
My two ideas are
' Given window, the one to start from ...
dim nextWindow, priorWindow
' Idea 1.
set nextWindow = window.control.next.window
set priorWindow = window.control.previous.window
' Idea 2.
dim windows : set windows = window.parent.directChildren
dim i
for i = 1 to windows.count
if windows(i).handle = window.handle then
set nextWindow = windows(i+1)
set priorWindow = windows(i-1)
end if
next
Plus error checking of course.
But I don't know if control.next/previous or directChildren sort by Z
order, so I'm not sure if one approach is more accurate than the other.
I'm also assuming that window.control is always valid for all Window
objects here.
Is there a better way of doing this, and if not, is the
window.control.next/previous.window method the preferred way of doing it?
