Thanks again Steve.
That helps again! Aaron is taking a look see at what I'm trying to do. I am
working on the same project, Visual Studio, al be it I'm in VWD with no com. So
he should have a interest in getting these controls working too.
He just wrote me the DataGridView is not a Standard control but asked me what I
was trying to do and I sent him a short WriteUp.
again, i am making very little headway scripting this bugger. I am working on a
Tutorial series for VWD and just wanted to build a quick script to make this
and a couple of other controls more accessible for nubes trying to use
Windoweyes.
If you are a programmer you know the screen reader environment used in our
field. Now that we have scripting, I want to get WE working well enough to
recommend it to Visual Studio programming and Web Development nubes.
Rick USA
----- Original Message -----
From: Stephen Clower
To: [email protected]
Sent: Tuesday, February 24, 2009 1:15 PM
Subject: Re: Audition Script Question
Rick,
I don't have all the answers, but I will endeavor to answer your questions to
the best of my ability below.
On 2/24/2009 10:50 AM, Ricks Place wrote:
I am slogging through some GW scripts trying to figure out what is going on.
In Audition and a couple of others they seem to be connecting to the
running application by connecting to some of it's MSAA Events I guess.
In the Audition script they seem to be using a variable called accObject as
a reference to something in the Running Application. First, where are they
getting the reference and defining the accObject variable value?
The MSAA data is first connected to an application through the
MSAAEventSource object. For example, the following lines set an object to the
event source, and the next one connects an MSAA event.
Dim myMSAAEventSource : Set myMSAAEventSource = MSAAEventSource
Dim msaaEventOnObjectFocus : msaaEventOnObjectFocus =
ConnectEvent(myMSAAEventSource, "OnObjectFocus", "OnObjectFocus")
Notice that I created a variable called msaaEventOnObjectFocus. The
ConnectEvent function will always return a number that references the specific
event, and by storing the event's reference, we can always check if the event
has already been hooked, and we can later disconnect it if we need to. It's a
good idea to always store these references so you don't accidentally connect
the same event multiple times. If you do, then Window-Eyes will execute the sub
or function for as many times as you connected the event. Believe me, this can
get ugly.
So, to put the above explanation into practice, my ConnectEvent routines
always look like:
Dim msaaEventOnObjectFocus
If msaaEventOnObjectFocus = 0 Then ' 0 means the event hasn't been connected.
msaaEventOnObjectFocus = ConnectEvent(myMSAAEventSource, "OnObjectFocus",
"OnObjectFocus")
End If
Now let's say I want to disconnect the event for some reason.
If msaaEventOnObjectFocus> 0 Then ' A number other than 0 indicates the event
has been connected.
Disconnect msaaEventOnObjectFocus
End If
Now as for this mysterious acc object, its presence is explained in the
events of the MSAAEventSource object. When you connect an MSAA event, you must
create your function to accept a single Accessible object, or accObj for short.
To continue the previous example, the callback for the OnObjectFocus might look
like this:
Sub OnObjectFocus(accObj)
If Not accObj Is Nothing Then
'... do something with the object.
End If
End Sub
Note: you could just as easily call accObj anything you want: oAccessible,
cousinFrank, focusObject, etc. We stick to accObj to keep things consistent.
All of the 50 MSAA events take an Accessible object as a parameter. Using
WeEvent to monitor your application's MSAA stuff will help you quickly find
which events you need to watch and how best to deal with the information they
present.
The Accessible object is explained in detail in the scripting docs. Also look
at Accessibles, AccessibleState, and AccessibleRole. In my experience, the
hardest part of working with MSAA was determining how to connect events into a
script to get the Accessible objects in the first place.
Second, I want to set and change properties in a DataGridView in the
Running Application
That means modify the existing instance of the control
So, how do I get a reference to the control so I can access it's
properties and methods?
Use the Window.Control method to return a reference to the grid. If the
control can be focused with the keyboard, I would move my cursor to it, open
the Window-Eyes immediate mode script, and enter
Dim gridControl : Set gridControl = FocusedWindow.Control()
Now I could do whatever I want with it. Or, if I wanted to look at the MSAA
info for the control, I would type
Dim accObj : Set accObj = FocusedWindow.Accessible
Then I could start examining the object I got:
Print accObj.Name
Print accObj.Value
And so on.
In VBS I think the Create or GetObject would be used but what about in
Windoweyes?
You only need to use CreateObject and GetObject if you want to interact
with a Com object that's produced by the program you're working with. The free
editions of Visual Studio offer no Com automation support, so you wouldn't use
these methods.
One more thing, what is an Overlp? From what I learned it was something on a
screen overlapping another item, here it looks like they mean the Running
Application. Is this the case?
An overlap represents the top-level window of a program. If you had an object
that was set to your grid view, then calling its Overlap method would return a
Window object representing the Visual Studio editor.
Hope this helps.
Steve
