Hi Rick,
The problem I had was in monitoring changes inside the Uninstall folder of
the Registry. In WMI there are 2 event processes and one of them is a
continuous call back flag that tells you when an event is ready to be read or
has completed. It works in Windows XP, but later systems, Windows7 and I am
sure Vista, there seems to be an issue with GW Micro in not catching that event
as it comes back. It recommends to use or send a certain flag to insure
completion and a return status and I think GW Micro is not sending that
request. Or is blocking that request for it may actually be using that flag but
not forwarding it...
So, I discovered when using that very same format in an external .vbs file
it works every time, and fails every time inside the GW Object model...for a
Windows 7 OS.
So, I think our problems are related and just maybe GW is what you might
call, "HOGGING" that event? And not forwarding it like you would see in call
back formats.
Bruce
Sent: Thursday, May 31, 2012 9:39 AM
Subject: Re: KeyProcessedDown working
I am reading up on WM and WMI from the Keyboard.
It is a rather complex process from the initial read through.
My guess is that the system still broadcasts messages, or this wm keyboard
stuff might not be in the later releases of the OS.
If that is the case then the UIA AutomationElement just filters messages
based on whether the Target Programmer has enabled patterns for this type of
input to a Client UIA script.
That said the MS docs talk about windows as we understood them in MSAA and
the WE Docs and does not talk about them in relation to AutomationElements so
there is that.
Anyway, I guess GW may need to address the problem as well if it is related.
Reading I find that messages are queued from and to the thread which fired
the event.
Trapping them in another thread and then trying to forward them might be the
problem with the Key>KeyProcessed methods- I have no clue but it sounds like
something that could be related.
This ui stuff is getting way complicated when all I want is an accessible
vb.net express to work on my vb.net express investment software platform!
Later:
Rick USA
From: BT
To: [email protected]
Sent: Thursday, May 31, 2012 8:52 AM
Subject: Re: KeyProcessedDown working
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
