ah. hmmm. again, my thanks for your response on this Don eh. when I'm done with this job, I'm gunna have to suss this out a whole lot more. this whole windows traversing lark. Geoff c. ----- Original Message ----- From: "Donald Marang" <donald.marang@xxxxxxxxx> To: <jawsscripts@xxxxxxxxxxxxx> Sent: Thursday, July 22, 2010 10:15 AM 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 > __________� View the list's information and change your settings at http://www.freelists.org/list/jawsscripts