[jawsscripts] traversing variable window hierarchys and usage of WindowName. is it absolute? or StringContains? questions?
- From: "Geoff Chapman" <gch@xxxxxxxxxxxxxxxx>
- To: <jawsscripts@xxxxxxxxxxxxx>
- Date: Thu, 22 Jul 2010 06:15:53 +1000
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
Other related posts: