Rick,
You did see the post where we stated this was a Window-Eyes bug, and
provided a work around, right?
Aaron
On 4/6/2011 6:21 PM, RicksPlace wrote:
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 <mailto:r...@gwmicro.com>
*To:* gw-scripting@gwmicro.com <mailto: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.
--
Aaron Smith
Web Development * App Development * Product Support Specialist
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
