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 <mailto:[email protected]>
*To:* [email protected] <mailto:[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
