Thanks for the kind words, Rick. You may be thinking of Sina Bahram, who I think is a PhD student at UNC. I'm a federal employee who mostly does data-related programming and analysis .
Regarding the Learn Scripting package, the text version of the Window-Eyes scripting manual does, indeed, have erroneous items in the table of contents at the beginning. I use a home-grown utility (written with WinBatch) to convert CHM files to structured text format. It treats the top line of an included HTML file as a section heading that is listed in a table of contents section, generated and placed at the beginning of the file. Evidently, that text is often not helpful as a section heading with that CHM file. I may do more manual work to refine that section when WE 7.1 is released. In the meantime, I think you will find useful text in the remaining sections of the file. Sections are seperated by a form feed and line break sequence, which EdSharp uses for navigation with the Control+PageDown and Control+PageUp commands. Regarding scripting VWD or VS generally, one option is to use the "Visual Studio Extensibility Model" for more functionality. Commercial versions of VS, but not Express editions, make a COM server available by which almost anything can be done -- similar to the object models of Word and Excel. You can Google for documentation about this on MSDN. Cheers, Jamal On Mon, 23 Feb 2009, Ricks Place wrote: > Date: Mon, 23 Feb 2009 06:47:53 -0500 > From: Ricks Place <[email protected]> > Reply-To: [email protected] > To: [email protected] > Subject: Re: General Concept Question > > Thanks Steve: > This is the Rosetta Stone! > I will do my homework now. It is not knowing what I don't know that is so > dificult! > Jamal is pretty cool too, he is a University Student if I remember and is > getting pretty dang good with technicals. > Thanks again and I'll see you on the flip side.Rick USA > Rick USA > ----- Original Message ----- > From: Stephen Clower > To: [email protected] > Sent: Sunday, February 22, 2009 11:59 PM > Subject: Re: General Concept Question > > > Rick, > > The SDK that you use with Visual Studio contains the bare essentials that > are needed to build Win32 programs. By itself, the SDK doesn't extend the IDE > in any way > > The object reference that you see inside the Window-Eyes help menu is > indeed a very detailed description of the screen reader's Com API. It can be > overwhelming at first-- especially if one doesn't know where to start > looking. Based on your questions, I would recommend looking at the Script and > Window objects first. By examining the Script object, you will gain an > understanding of how to connect Window-Eyes events inside a script. The > Window reference contains the events, methods, and properties you need to > find and monitor any operating system or application window. You might then > want to look at the Keyboard object to learn how to register hotkeys. After > that, examine whichever objects you believe will help you in reaching your > script's goals. > > Some invaluable scripts that have helped me navigate a few conceptual and > technical hurdles include WeEvent, Immed, and Virtual Explorer. WeEvent makes > it easy to hook any of the Window-Eyes events to an application and watch > what happens in real time. The event log can then be studied as it populates > or saved for later review. > > Immed is GW Micro's immediate window script. If you want to test out a few > lines of code without writing a full-blown script, then this is an essential > time saver. > > Virtual Explorer is written by Jamal Mazrui and enables you to graphically > explore windows and their relationships. > > Now that I've summarized the scripts, here's a brief overview of how I use > them to make my life easier. I first invoke Virtual Explorer when I'm inside > the program I want to script. I can quickly look at every window inside the > app (including window titles, text, style information, handles, class names, > etc). If I later decide I want to monitor one of these windows, I can use VX > to quickly obtain the information I need. Once I have a general idea of the > application's structure, I pull up WeEvent and select various events to > monitor. Nine times out of ten, I select all of the available MSAA options, > tab back to my application, and use it for a minute or two to allow plenty of > data to accumulate in the WeEvent log. I'll then go back to WeEvent and study > the results of the monitoring. This step can, and usually does, take some > time. Once I know what I want to monitor, I can open Immed to write out a > quick code snippet to accomplish this and observe what happens. I then add > the snippet to my script once I have it working the way I want. > > Aside from looking through the Window-Eyes object reference and using the > above scripts, you might be amazed with how much you can learn from actually > reading through a script itself. Nearly all of the packages on Script Central > contain human-readable code that is filled with explanatory comments. I > learned a great deal about how to connect and interpret MSAA events, for > instance, by reading through Aaron Smith's Adobe Audition 3 script. > > Hope this helps. > Steve > > On 2/22/2009 11:04 PM, Ricks Place wrote: > Thanks Steve: > There is the Windows API, VBScript and the Windows DLLs and Framework. I > use to use the Windows DLLs to access some information about windows > controls and modify them with the DLLs. > So I sort of get making calls to Windows DLLs from a script to access > system properties or events. Now, Windoweyes says they have an API that > provides direct access to the controls of a running application like Visual > Studio. > Is the definitions of the Objects in their reference document the > documentation for their API? Do you know the commands you would put into a > script to find a button with some name or handle inside a given window or > dialog. Then, once found set focus to it and pressit or fire it's activation > event somehow? > The sum total I found in the GW documentation was how to display a > couple of message boxes. Nothing on interacting with controls in a running > program let alone using MSAA nor the new UIA or whatever it's called. > What is their SDK all about? I haven't seen anything on using that > either. > Thanks Rick USA > ----- Original Message ----- > From: Stephen Clower > To: [email protected] > Sent: Sunday, February 22, 2009 1:22 PM > Subject: Re: General Concept Question > > > Rick, > > This might work if the VWD software supports Com automation and if the > gridview control can be manipulated as an object. I honestly don't know if it > does, but the idea is sound. > > You can also pull up the WeEvent script and monitor the MSAA > information that the gridview sends out and write a script to intercept and > speak the data. > > Best regards, > Steve > > > On 2/22/2009 6:45 AM, Ricks Place wrote: > Hi: > I have a GridView I want to make work better. Would I instantiate a > instance of it using the get object command? > Can I assume it's properties and methods would then be available in > my script? > Would I use a Windows Control to display a more Windoweyes Friendly > version of the Data and allow for adding new rows and cells? > Rick USA > > > >
