Hi Ron et al:
I ran the following tests before I read this post Ron...
It is very interesting and I will think on this process overnight to improve my
understanding of how things happen.
Here are the recent tests which include removing the WatchEvent statements all
together with interesting results. Again, Ron, I will think on these results in
light of my new understanding of the process and try something or post up again
tomorrow.
Test01:
I changed the MyApp Global variable which holds WindowEyes.Application
and the MyMsaaEvent Source Global variable to Private.
It seems to make no diference.
Ron, you were right in this post.
My Second test I commented out the Blockevent code as Chip had mentioned and
asked about.
Then I ReBooted the computer and opened CSharp, the application associated
with the VB.net, script.
The WatchEvent and the MSAA OnFocus were working as usual with the VBScript I
wrote for Chips class running.
I alt tabbed to windoweyes and stopped the VBScript for Chip's class.
The MSAA OnFocus event in the VCSharp application, in my VB.net Script,
continued working unlike, if I remember, in prior tests.
I also noticed that While in the WindowEyes Scripting Manager every time i
moved around using the cursor or tab,
changed focus in the WindowEyes Script Manager,
the OnObjectFocus event in my VB.net Script associated with the CSharp
Express Application fired.
This happened after leaving the WindowEyes Script Manager in the DeskTop as
well.
So, once I had started having the OnFocus event start firing in the VB.net
Script it continued to fire upon any focus change in any application so long as
I did not exit the CSharp Application and trigger the OnShutdown Process of my
VB.net script associated with the CSharp Express application.
This also makes me question where the problem lies.
If it is in my VB.net script the OnObjectFocus should not fire outside that
script as I filter the MyMSAAEventSource on the ClientInformation process.
To see if I could get a diferent MSAA Event to work per another request,
I added the following line to wire up the OnObjectStateChange event in the
Main Module where I have the OnObjectFocus initialized.
MyMSAAEventSource.WatchEvent( WindowEyes.MSAAEventID.event_OBJECT_STATECHANGE)
I added the following sub with the Handles clause to handle the
OnObjectStateChange event of the MyMSAAEventSource Object.
Private Sub MyMSAAEventSource_OnObjectStateChange( AccObj As
WindowEyes.Accessible) _
Handles MyMSAAEventSource.OnObjectStateChange
Speech.Speak( "On State Change Sub Entered")
Logger.WriteLine( "On State Sub Entered")
End Sub
Then I opened the CSharp Express Application which is associated with my
VB.net Script.
The OnObjectFocus event fired but I could not get the OnObjectStateChange
event to fire.
Final test for tonight:
I commented out the WatchEvent statements so there was no hooks except the
handles clause in the Subroutine.
This means there should be no way for the OnObjectFocus to fire.
When I opened the CSharp Express App which is associated with the VB.net
Script the OnObjectFocus continued to fire.
My Log indicated that although firing all the time the AccObj, the assecible
object of the OnObjectFocus event was always set to Nothing.
I will have to think on these results a little to see if I can figure out
another test or what might be a common issue here.
With the WatchEvent comment out and the OnFocus Handler sub still getting
fired on any focus change inside, or outside, the filtered MyMSAAEventSource I
need to ReThink my understanding of how a message gets from my hitting keys and
changing my cursor focus, to WindowEyes and then back into my VB.net Script to
tell the Subroutine with the OnObjectFocus Handler to fire and why the
Accessible Object that should be getting passed into that sub is always nothing.
One more note, this might make a little sense after my first read of this
post from Ron and I will dig into the possibilities tomorrow to see if I can
test anything that might help.
I might be able to dig in a little deeper by monitoring some interop, system
or other variables if it appears I can do it and it might shed some light on a
solution.
Also, I can ReVisit my code after studying what Ron posted in this message to
see if anything jumps out at me.
See you tomorrow and thanks again for the help.
Rick USA
----- Original Message -----
From: Ron Parker
To: gw-scripting@gwmicro.com
Sent: Wednesday, April 06, 2011 4:06 PM
Subject: Re: External Script MSAAEvent Problem continued
On 4/6/2011 3:48 PM, RicksPlace wrote:
I will actually run one more test, in that one everything will be the same
as it now stands without modification except I will make the Global
MyMSAAEventSource variable private to see if that stops the bleeding of the
ConnectEvent from my VBScript into the VB.net Script and post the result of
that test with the above mentioned second Msaa Event test.
It won't stop the crosstalk. That behavior is just part of how Window-Eyes
does things, in part because COM Automation event handling doesn't (in general)
provide an easy way to find out what events a given listener actually cares
about, so we send every listener any events we have. Since the events we have
are the union of all the events any scripts asked for - either through explicit
means like WatchEvent or implicit means like the hosted
ConnectEvent/ConnectObject - there's a good chance we have events you don't
care about, and will ignore.
The same is true of all other event handlers. If you're handling Window
Focused events, some of the runtime code underlying your object will also get
Window Activated events. It just won't do anything with them, because you
haven't told it to do anything.
The good news is, if everything were working as designed, you'd never even
have known about this and it wouldn't be a problem.
The other good news is that your telling us about seeing that crosstalk is
what made it so easy to figure out what'd gone wrong. So thank you.
