So just to clarify, am I correct in saying that (1) this issue only
affects onFocus, or does it affect all MSAA events?  And (2) does it
affect only external scripts, or also hosted VBScripts and
Javascripts?

On Wed, Apr 06, 2011 at 03:06:56PM -0400, Ron Parker wrote:
   Yep, this is definitely our bug. This worked at one time, but at some
   point before the release of WE 7.0, something in the internal
   architecture got changed and that method didn't get updated. Which
   wouldn't normally be a problem, or at least not a problem anyone would
   find out about, but the original test case somehow also didn't get
   added to the regression suite. It'll be fixed in future versions.
   For now, we do have a workaround for you. It might not make much sense,
   but it should make things work, and it shouldn't incur any performance
   penalty. Basically, declare TWO objects of type MSAAEventSource, one
   with events and one without, set up the watched events in the
   without-events object, then copy the without-events object into the
   with-events object, like so:
       Private firstMsaaEventObj As WindowEyes.MSAAEventSource
       Private WithEvents msaaEventObj As WindowEyes.MSAAEventSource
       '... other code here ...
       Dim weObj : weObj = CreateObject("WindowEyes.Application")
       firstMsaaEventObj = weObj.MSAAEventSource

   firstMsaaEventObj.WatchEvent(WindowEyes.MSAAEventID.event_OBJECT_FOCUS)
       msaaEventObj = firstMsaaEventObj
   On 4/6/2011 12:08 PM, Ron Parker wrote:

   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

-- 
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug....@ssbbartgroup.com  http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller

Reply via email to