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
