Hi Rick,
Yes, I ran into the same problem in my Uninstall program. The WMI events
Windoweyes is not getting them.
I think there is a WE problem in capturing the WMI events and they should
fix it. I spent over a week on this issue, if you do a standard Script
operation the events come in, but when you do the same thing inside the WE
model, no event comes in.
So, what you are experiencing Rick is a Windoweyes object event capturing
problem and not anyone else's problem
Bruce
Sent: Thursday, May 31, 2012 7:19 AM
Subject: Re: KeyProcessedDown working
Hi: I have set focus to the File Menu on the Menu Bar.
But, when I close the menu bar focus returns to Solution Explorer even though
it is off screen.
Reading it looks like MS may be setting a virtual focus, or logical focus,
and whenever there is no focused object on the Main window focus is returned to
Solution Explorer even though it is off-screen, at least it's children are off
screen which is what is grabbing focus.
I was looking at Windows Management (system.Management) options for handling
keyboard input next.
The fact that the WindowEyes Key>KeyProcessed operations do not seem to work
properly may be an indication that WMI uses the broadcast method of message
processing.
UI Automation abandons that method and uses a method whereby only events
which have been explicitly subscribed to can be processed for a
AutomationElement if I read it right.
Thus I have found no Keyboard handlers other than Patterns to handle synch
and asynch events which the original vb.net 2010 express Programmer has written
code to provide to Clients like WindowEyes or me for that matter.
Since I dont see those patterns associated with any of the elements I have
looked at using ISpy I am guessing that Keyboard Input can not be accessed
directly using UI Automation for VB.net 2010 Express.
That leaves WMI, actually the operations in the System.Management namespace
as the only other method I can think of.
I am going to test it out but am afraid I may not be able to make it work to
duplicate the original intent operation of the WindowEyes>Key>KeyProcess method
but it might be possible - wont know until I go through that learning
curve,sigh.
I will post up asking GW guys if they know of any ramifications of that
particular process, Broadcast messages versus Subscribed message handling,
phew!If you have anything on all this let me know since I am getting pretty
burned on just trying to hide Solution Explorer from WE reading and processing
while not visible to sighted users.
Rick USA
----- Original Message -----
From: Chip Orange
To: [email protected]
Sent: Tuesday, May 29, 2012 9:30 PM
Subject: RE: KeyProcessedDown working
That is the active window (the solution explorer) to you just set focus to
itself. find some other window and set the focus there and it should leave the
solution explorer.
hth,
Chip
--------------------------------------------------------------------------
From: RicksPlace [mailto:[email protected]]
Sent: Tuesday, May 29, 2012 9:34 AM
To: [email protected]
Subject: KeyProcessedDown working
Hi: I was able to use the KeyProcessedDown Event handler to find the "x"
on the Solution Explorer form (the hide button" and click it programatically.
The Solution Explorer closes as it should and the screen goes dark.
WE still holds focus so the original problem is still there.
I just need to figure out how to get WE not to hold focus on the window
it is still on after Solution Explorer is hidden.
I posted a question to that effect a few minutes ago.
i tried setting focus to the Active Window but that did not help.
If I get that working this puppy will finally be done and I can move on
to the next accessibility fix.
Rick USA
