Thanks Chip: I'll try the code out.
Since I am working with a script which uses synchronized processing andworks
on another program, vb.net 2010 Express, which uses synchronized processing and
the WE Server which also uses synchronized processing and WMI, by default, uses
synchronized processing there is the distinct possibility for either lost
information or deadlocks.
I just dont have any tools to monitor the flow of messages and parameters
between all processes and threads to try and determine where things are getting
mucked up.
I am not a Software Engineer, just a simple Applications Programmer and a
blind one at that.
Anyway, I will look over your code to see if there is anything new to try out
before just hacking something and moving on.
If I need keyboard access I may elect to do something like low level access
but that is not a good thing to have in my script since I would like to keep
everything high-level and within Managed Code as much as possible.
Since I have not heard from Aaron at GW I am guessing there is no way to
determine the problem or fix or they are just too busy with the next release of
WE or something to worry about something this far out of the mainstream
scripting say in VBS.
So, thanks guys and I will be moving on after looking at Chip's code block
unless I get any ideas of something new to try.
I want to get back to learning and working in the UIA environment.
Later:
Rick USA
----- Original Message -----
From: Chip Orange
To: [email protected]
Sent: Tuesday, June 12, 2012 5:25 PM
Subject: RE: WOM Seems Flawed for Keyboard Input Handling
Hi Rick,
Below is a test app which works just fine for me. It blocks the onkey down
and onkey up for a key for 15 seconds, and speaks to you each time the onkey
down and onkey events fire.
I used the down arrow as the key to block, but of course you can use any key.
I am very sure WE isn't suppressing the handling of keystroke events; there
are simply to many programmers who do things with them (like I do in the Office
app I mentioned); we'd know by now if there's a problem.
Yes, there could be a larger issue with event handlers written in visual
studio, we might not know about that ... but I doubt there's a problem there.
Still, if there were, we'd see it in all events.
-------------
Option Explicit
Dim downArrow
Dim downArrowEvent1, downArrowEvent2
Set downArrow = keyboard.key("down arrow")
If downArrow Is Nothing Then
Speak "failed to get down arrow"
Else ' downArrow Is Nothing
' now can trap the key down and up events for the arrows to prevent window
eyes from speaking anything;
' otherwise, WE will repeat the line of code.
' down arrow
downArrowEvent1 = ConnectEvent(downArrow, "onKeyDown", "downArrowOnKeyDown")
downArrowEvent2 = ConnectEvent(downArrow, "onKeyUp", "downArrowOnKeyUp")
End If ' downArrow is nothing
Speak "for 15 seconds this app will block the down arrow key from being seen
by window eyes. Instead, it will announce each time you press the down arrow,
that it was blocked."
sleep 15 * 1000
disconnect downArrowEvent1
disconnect downArrowEvent2
Speak "no further blocking of down arrow."
Sub speakText(msg)
Speak msg
End Sub
Function downArrowOnKeyDown(ByVal VirtualKeyCode, ByVal KeyModifiers)
' event handler
downArrowOnKeyDown = kdDiscard
queue "speakText", "down arrow key down discarded"
End Function
Function downArrowOnKeyUp(ByVal VirtualKeyCode, ByVal KeyModifiers)
' event handler
downArrowOnKeyUp = kdDiscard
queue "speakText", "down arrow key up discarded"
End Function
----------------------------------------------------------------------------
From: RicksPlace [mailto:[email protected]]
Sent: Tuesday, June 12, 2012 5:38 AM
To: [email protected]
Subject: WOM Seems Flawed for Keyboard Input Handling
Hi Guys:
I have just finished monitoring OnKeyDown,OnKeyUp, OnKeyProcessedDown,
OnKeyProcessedUp and got the same results I always get.
The OnKeyDown and OnKeyProcessedDown event handlers fire but not the
OnKeyUp nor the OnKeyProcessedUp event handlers and I get no results with the
Target Program.
I then pulled the OnKeyDown and OnKeyProcessedDown handlers out so only the
OnKeyUp and OnKeyProcessedUp event Handlers fired.
Again, the OnKeyUp and OnKeyProcessedUp handlers now fire whenever I press
a key but then the system seems not to respond to any key commands and I cant
even close the vb.net ide - all keys seem to be disabled or not passing
commands to the target program or something.
I know this may be the case with OnKeyUp with no OnKeyDown if the Returned
value is not the same as the OnKeyDown but it happens the same for both
handlers OnKeyUp and OnKeyProcessedDown and happens the same when I first use
OnKeyDown along with the OnKeyUp handler as mentioned above.
The keyboard input essentially seems to lock up.
Due to the results I am getting I am pretty much convinced Bruce is onto
something with his Async problem of the WindowEyes Object Model.
If WE is using WMI under the covers to process the OnKeyDown and OnKeyUp
and OnKeyProcessedDown and OnKeyProcessedUp then I think it sure sounds like
Bruce may have hit on something.
To check it out I was thinking of somehow trying to monitor what is
actually getting passed into the target program and to windoweyes when these
handlers are invoked but am not sure how to do it.
I tried running vb.net 2010 express with my script active and then running
WEEvent to see what that tells me but even WEEvent does not respond once I have
set the Keyboard input to use the OnKeyProcessedUp or OnKeyUp event handlers -
note that I didnt filter the event handlers on process so the Keyboard input
seems locked up even in WEEvent.
Can you think of a particular test which may monitor what is actually
happening within the WE Model and the underlying Target Application (vb.net
2010 Express)?
Perhaps I can filter the Keyboard event handlers if that filtering process
would work but if there is a problem with WindowEyes and WMI and it uses WMI to
filter then I will still get bad results.
Before I try filtering and guessing do you have any ideas of how best to
verify if there is a Async, or other, problem with WE.
Again, if you have code using these handlers in one of your vbs apps
running under we let me know and I will read it to see if I am missing
something.
It is sounding more and more like Bruce has found a major bug in the WOM
(WindowEyes Object Model) - I hope not though.
That or there may be a problem with the way WE handles keyboard input
related to external scripts.
Thanks:
Rick USA
