Hi Jamal:
Actually the PHD candidate in question was Will Pearson. I did not know Sina
was headed there too. The original developers of the JAWS scripts was quite
a team! You, Ken Perry, Sina, Chris, Will and others.
I don't think we will see the likes of that team anytime soon.
Will and Sina headed toward PHDs, Will a Microsoft GURU and VIP, Chris a
former big wig at Freedom Scientific, Ken an experienced programmer and good
with accessibility issues you and a few other pretty dang good programmers!
I am one old gray haired Applications Programmer and now find I need to
script VWD to get it to work properly.
So, as Oliver often said to Stanley, Another Fine Mess! Or, more in your
generation as Skully once said to Mulder, Sure, Fine, Whatever!
Or as the sports guys are fond of saying, it is what it is! - grin.
See you on the flip side Jamal, you are getting pretty bloody good from what
I've seen of your work.
Rick USA
----- Original Message -----
From: "Jamal Mazrui" <[email protected]>
To: <[email protected]>
Sent: Monday, February 23, 2009 10:38 AM
Subject: Re: General Concept Question
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
