To be honest, it is very difficult to keep up with the thread and
exactly what the questions are. Is there a concise question that we can
answer?
Doug
On 6/13/2012 10:51 AM, Chip Orange wrote:
Hi Rick,
If you don't hear from GW I wouldn't assume anything except they're
busy. I believe when they have the time they will help us with our
programming, but if they're busy and we're having some issue where our
programs aren't working, I wouldn't be surprised if they do not step
right up and say "after spending much time analyzing your program,
here's where you are going wrong."
I don't believe there is any issue when developing an app which uses
both synchronous and asynchronous interactions with other programs;
most of us do this all the time, I don't think it implies loss of
data. Almost all of the published apps are doing this.
If you are trying to debug with "speak" commands for instance, and the
speech itself is changing things or otherwise getting in the way, try
other forms of debugging such as the WE clipboard object and its
appendText method; it works nicely, and after a questionable segment
you can dump the clipboard into notepad and study what just took
place. rarely does adding information to the clipboard interfear with
any event handling.
I posted what I did to show you the onKey handling isn't broken, but
also, to promote the idea that when you're getting really confused
because things aren't working; strip things down to the minimum
necessary to test one idea at a time.
As I recall your quest was how to deal with the user pressing a key
and closing the solution explorer, which didn't leave WE in the state
you wanted.
Really, if I have the problem right, there's no doubt you need to be
registering a cursorKey when the solution explorer is active. try
writing a program which does this, and in the cursor key handler
insert some statement into the clipboard to show you it was handled.
Don't do anything else except to unregister the cursor key at the
proper time, and see if that much works or not.
hth,
Chip
------------------------------------------------------------------------
*From:* RicksPlace [mailto:[email protected]]
*Sent:* Wednesday, June 13, 2012 4:53 AM
*To:* [email protected]
*Subject:* Re: WOM Seems Flawed for Keyboard Input Handling
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 <mailto:[email protected]>
*To:* [email protected] <mailto:[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
