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
