[jawsscripts] Re: traversing variable window hierarchys and usage of WindowName. is it absolute? or StringContains? questions?
- From: "Homme, James" <james.homme@xxxxxxxxxxxx>
- To: "jawsscripts@xxxxxxxxxxxxx" <jawsscripts@xxxxxxxxxxxxx>
- Date: Thu, 22 Jul 2010 07:37:04 -0400
Hi Geoff,
Is there any pattern at all to the information about the windows in this
application?
Thanks.
Jim
Jim Homme,
Usability Services,
Phone: 412-544-1810. Skype: jim.homme
Internal recipients, Read my accessibility blog. Discuss accessibility here.
Accessibility Wiki: Breaking news and accessibility advice
-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Donald Marang
Sent: Wednesday, July 21, 2010 8:16 PM
To: jawsscripts@xxxxxxxxxxxxx
Subject: [jawsscripts] Re: traversing variable window hierarchys and usage of
WindowName. is it absolute? or StringContains? questions?
A good way to see if the hierarchy changes between sessions, follow the
scenario below. Run your program, move to the desired window / object,
enter the BX Toolbox and get the object's path. Write it down. Now exit
the program and restart the computer. Run the application again. If it is
an application that has a lot of different dialogs that come and go, play
around with the application for a while to force it to create and destroy
many windows and branch out its structure, then prune it back. Now move to
the desired window / object again and activate the BX Toolbox. Check the
path and see if it has changed from the previous time. Note the entire path
does not need to stay constant. I have never needed to compare more than
two levels. In real terms, I only needed to look at the relative path of
the control, it's dialog, and occasionally the parent of the dialog. New
Wal-Mart announcement, "Will the parent of the lost control please report to
Customer Service.".
Don Marang
--------------------------------------------------
From: "Geoff Chapman" <gch@xxxxxxxxxxxxxxxx>
Sent: Wednesday, July 21, 2010 4:15 PM
To: <jawsscripts@xxxxxxxxxxxxx>
Subject: [jawsscripts] traversing variable window hierarchys and usage of
WindowName. is it absolute? or StringContains? questions?
> I'm just wondering here. Given the very helpful and I'm certain live trap
> that Don mentioned today, of needing to watch whether window hierarchy's
> changed from one session run to the next, as they are created and released
> etc,
> well, I was just about to start maybe trying to do a messsy, and
> never-before tried,
> prior/nexst window deal, to uniquely navigate to my windows of interest,
> in this app I'm scripting.
> but, then I noted don's warning, and thought this might not be thus, a
> very reliable way of doing this?
> Goes without saying that there's no unique control ID's for these windows,
> they equal the handles and thus change every time the app is run.
> But, I'm kinda running out of options here, since I've discovered, that
> whilst I can use FindWindow, well enough, to locate a window with a
> particular unique name, even though the class is the same for all of them,
> for my trunk buttons in this telephony app, I've just discovered, that it
> appears WindowName, as the third parameter of FindWindow, is, not, gunna
> work for my station/extension button windows here, because, it seems the
> name, is also not static, in that it incorporates the name of any given
> trunk, that gets transferred to it, into it's actual windowName!
>
> Now so here's my questions around this:
>
> Does anyone know, whether the windowName as the third parameter of
> FindWindow, has to be, an exact match? and only an exact match? or does it
> work on a more "stringContains, type basis? this is not specified in the
> fsdn! grrrr!
> For example: I'm wanting to reliably click in windows, which will change
> the last part of their Window names dynamically, but, which retain the
> first part statically. as in:
>
> "EXT 102
> Brad"
>
> might be the name of a given extension buttonn's window at one time, but,
> then when this obtains a trunk call transferred to it, the lower line
> here, changes, to, say,
> "EXT 102
> TK: 801"
>
> Thus, of course for findWindow, if it utilizes an exact match principle,
> this method isn't gunna fly for me eh.
> But, if it uses a stringContains type method, then, I could just use the
> "EXT 101" as my window name, and it might work?
>
> I know I could test this for myself I guess, but, if anyone knows off the
> tops of their head as to this, could they perhaps be kind enough to let us
> know?
>
> and/or, in these conditions, and if findWindow does want an exact match
> for it's third windowName parameter to be happy,
> would traversing the window hierarchy, be pretty much the only game left
> in town?
>
> Save Jim Bower's totally different Idea I hadn't thought of,
> that he threw me the other night, which I'm about to test out here, which
> again relies on the window of interest remaining in a static relationship
> to the top left corner of the appMain Window, which I think these all do,
> but I can't vouch for their backEnd hierarchy window tree structure as
> being static?
>
> Actually whilst on that, here's a question.
> now, hee hee, could doug's bX ToolBox, do something like this? take some
> sort of snapshot of the window hierarchy tree, and then, either
> automatically, or, probably mor realistically upon request,
> provide knowledge of when that relationship changed at all?
> Such that, for example, I could know, before I tried coding it up, whether
> the backEnd hierarchical structure of these windows, remained static
> enough to utilize walking the branches to locate a given window of
> interest?
>
> now, that would be very sweet! would not it?
>
> thanks for listening. comments?
>
>
> geoff c.
> __________�
>
> View the list's information and change your settings at
> http://www.freelists.org/list/jawsscripts
>
__________�
View the list's information and change your settings at
http://www.freelists.org/list/jawsscripts
This e-mail and any attachments to it are confidential and are intended solely
for use of the individual or entity to whom they are addressed. If you have
received this e-mail in error, please notify the sender immediately and then
delete it. If you are not the intended recipient, you must not keep, use,
disclose, copy or distribute this e-mail without the author's prior permission.
The views expressed in this e-mail message do not necessarily represent the
views of Highmark Inc., its subsidiaries, or affiliates.
__________�
View the list's information and change your settings at
http://www.freelists.org/list/jawsscripts
Other related posts: