Hi Doug,
Yes, and I will second that for Chip and Rick. I first discovered this
issue when doing my Uninstall program for an XP person and it works inside the
XP machine, but, not on a Windows 7 machine, the UI form does not allow the
Async event to come through. Yet, on the Windows 7 machine as Chip mentioned
below it does come through when outside the WE Script.
Only when on a Windows 7, (Maybe Vista also,) does the Async event get
blocked inside the WE Model, but not outside the WE Script Model.
Rick attempted the same thing using the same WMI event, but not for a
registry WMI Async event like I did but for a keyboard WMI, but he got the same
result I did, "NO" event coming back.
I am not sure if this is an (register event issue) or you are using the
event but not bubbling it beyond where you are using it. I don't know for I do
not have your C code or what you are using to run the WE Script for UI machines.
So, I hope this can narrow down the issue further then what Chip mentioned.
(I have not responded to this thread recently because I had changed my email
address.)
Bruce
Sent: Wednesday, June 13, 2012 1:56 PM
Subject: RE: WOM Seems Flawed for Keyboard Input Handling
Hi Doug,
I will let Rick decide which question he would like to ask.
In all of the discussions, one point has arisen which I am curious about:
there are vbScript examples available on the internet showing use of WMI and
asynchronous processing of your WMI queries (looks like ordinary event handling
to me). These examples work when run in VBScript outside of WE (that is, run
with WScript); they do not work when kicked off by WE from the app manager, and
using the VBScript environment provided by WE.
The questions are why? and does this have any effect on any other event
handling which may be done by apps, internal or external to WE?
Thanks.
Chip
----------------------------------------------------------------------------
From: Doug Geoffray [mailto:[email protected]]
Sent: Wednesday, June 13, 2012 12:39 PM
To: [email protected]
Subject: Re: WOM Seems Flawed for Keyboard Input Handling
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
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
