We're looking into this. As of right now, we can't rule out the
possibility that a bug has crept into the implementation of WatchEvent.
If so, we'll of course fix it and see what we can do about developing a
workaround you can use until the fix hits the streets.
On 4/6/2011 11:31 AM, RicksPlace wrote:
Hi Ron and Chip:
I hope the following clears up a couple of questions I have seen in a
couple of posts on this subject.
If you know of an external sample script using MSAA Processing,
preferrably the OnFocus event, let me know so i can look at it and we
can try to avoid the following mess...
OK. I reviewed things at the Application Programming level. That is I
reviewed the docs on how to handle events in VB.net, the WindowEyes
Docs on the events I subscribe to in my script and my script code
related to these events.
In VB.net you usually use the Handles clause to subscribe to an event.
The Handles clause indicates which Sub to fire when a subscribed event
is triggered.
There are other ways of doing this,including the use of delegates,
but this is the most robust and commonly used method.
In my code I have the OnShutdown event wired up using the following
statements and they work:
' The following is a global variable
Public WithEvents MyClientInformation As WindowEyes.ClientInformation
' In the Main Sub
' Set Up the ClientInformation
Try
MyApp.ClientIdentify(System.Diagnostics.Process.GetCurrentProcess().Id )
MyClientInformation = MyApp.ClientInformation
MyClientInformation.ScriptName = "RicksWEComScript"
MyClientInformation.ScriptDescription = "This is my test script for
the vb.net interface"
MyClientInformation.ScriptHelp = "This is a help string in ClientInfo."
Logger.WriteLine( "ClientInformation Initialized OK")
Catch ex As Exception
Logger.WriteLine( "ProblemInitializing ClientInformation in MainSub")
Logger.WriteLine( ex.ToString())
End Try
' The sub in the module
Private Sub clientInformation_OnShutdown() _
Handles MyClientInformation.OnShutdown
Speech.Speak( "Shutting Down Now, ByeBye")
Logger.WriteLine( "Shutting Down Now")
Application.Exit()
End Sub
The above setup works as I would expect.
I create an instance of the ClientInformation Object called
MyClientInformation.
I subscribe to It's events via the WithEvents Clause.
When any event on MyClientInformation has been triggered,
My App automatically handles the event based on the Handles Clause of
the above subroutine.
Here is the code to the BlockEvent which also seems to be working:
' Global variable
Public blockFocusEvent As WindowEyes.MSAAEventBlock
' In the Main sub
' Initialize the BlockFocusEvent
Try
BlockFocusEvent = MyMSAAEventSource.BlockEvent(
WindowEyes.MSAAEventID.event_OBJECT_FOCUS,
MyClientInformation.ApplicationProcess )
Logger.WriteLine( "BlockFocusEvent Initialized OK.")
Catch ex As Exception
Logger.WriteLine( "Error Initializing the BlockFocusEvent")
Logger.WriteLine( ex.ToString())
End Try
Note that the BlockEvent is a method of the MSAAEventSource object as
is the WatchEvent method.
The Block event seems to be working and returns a variable to use to
unblock as you mentioned in your post.
Question: The WatchEvent is a sub and does not return a variable so it
seems to function diferently with no variable to set to nothing to
disable the WatchEvent. How would this be accomplished?
Finally:
Here is the code related to the OnFocus Event:
' Declare the Global variable with events as with the MyClientInformation
Public WithEvents MyMSAAEventSource As WindowEyes.MSAAEventSource
' Initialize MyMSAAEventSource and Filter on Process
' In the Main sub
Try
MyMSAAEventSource= MyApp.MSAAEventSource
MyMSAAEventSource.Process = MyClientInformation.ApplicationProcess
Logger.WriteLine( "MyMSAAEventSource Initialized and Filtered OK")
Catch ex As Exception
Logger.WriteLine( "Error initializing MSAAEventSource")
Logger.WriteLine( ex.ToString())
End Try
' Notice this sub uses the handles clause the same way as the
handles clause of MyClientInformation.OnShutdown sub which works.
' The sub in the module
Private Sub MSAAEventSource_OnObjectFocus( AccObj As
WindowEyes.Accessible ) _
Handles MyMSAAEventSource.OnObjectFocus
If AccObj Is Nothing Then
Logger.WriteLine( "Hit: AccObj was nothing in sub")
Speech.Speak( "Hit in the focus sub")
Else
Logger.WriteLine( "Hit: AccObj was nothing")
Speech.Speak( "Hit in the focus sub")
End If
If Not AccObj Is Nothing Then
AccObj.SimulateEvent( WindowEyes.MSAAEventID.event_OBJECT_FOCUS,
WindowEyes.AccessibleProperty.apAll)
End If
End Sub
Note: Since I handle the OnFocus event the same way as the OnShutdown
event which is working, I can't seem to figure out why the OnFocus
event is not causing the sub to fire.
It is mmy guess that the windoweyes notification of an OnFocus event
should come from the MyMSAAEventSource object as the event
notification does for the OnShutdown event of the MyClientInformation
object.
Now, Ron:
This is major wierd...
I just completed creating a Global VBScript to go along with Chip's
Windoweyes class.
It uses a ConnectEvent to a MSAAEventSource to connect to the OnFocus
Event inside the VBScript.
After testing my VBScript I considered that script complete.
I ReVisited my VB.net script to see if I could figure something out to
solve my problem with the VB.net script.
I just opened CSharp, the Associated Application to my VB.net script,
and the OnFocus event fired and was working properly!
I found out that if I had my VBS Global Script running that my VB.net
Script's OnFocus event works as expected - likely due to the
ConnectEvent in the Global VBScript?
If I turn off, stop, the Global VBScript, My VB.net Script's OnFocus
event does not work again.
Also, If I close the CSharp App, and thus the associated VB.net Script
and ReStart CSharp again, the OnFocus Event of the VB.net script does
not work.
This is the case until I ReBoot my computer in which case My Vb.net
script will process the OnFocus event the first time I open the
CSharp.net program and thus my VB.net script,
so long as my Global VBScriptt with the ConnectEvent method is running.
I have no clue as to what is going on except that the Event Handling
event connection seems to be bleeding between my VBScript script and
my VB.net script.
Things I might shotgun if you have no ideas:
Try and replace the Handles clause methodology with a direct Delegate
function hookup if the necessary details are available,
Try and instantiate and execute a second instance of the main process
as you did in your sample although this should not be necessary from
my understanding of how Microsoft handles instantiation of a new Main
Process.
Also, along these lines, I originally had my code in the instance of
the Pump Class which was run explicitly and had the exact same results
as I did subsequent to moving all the logic into the Main Module.
That makes me think that the problem is not dependent on the instance
that is run directly itself.
So, any ideas or perhaps examples you can suggest?
ThanksGuys for any ideas or suggestions:
PS, I may not even end up using an external script for some
performance reasons I seem to be running into but getting it working
in the first place would let me explore this situation prior to giving up.
Rick USA
