Indeed Chip: I did return the Process and Pass enums but had no other code.
Rick USA
----- Original Message -----
From: Chip Orange
To: [email protected]
Sent: Tuesday, June 12, 2012 5:27 PM
Subject: RE: WOM Seems Flawed for Keyboard Input Handling
Hi Rick,
I don't believe you can leave an onKeyUp or onKeyDown handler empty; you need
to return a handling code to WE, and it should be the same disposition for both
the down and up event.
Chip
----------------------------------------------------------------------------
From: RicksPlace [mailto:[email protected]]
Sent: Tuesday, June 12, 2012 8:36 AM
To: [email protected]
Subject: Re: WOM Seems Flawed for Keyboard Input Handling
Hi Bruce:
OK, I will try a single speak.
In fact, I will just leave the handler totally empty just to see if the
keyboard input continues working.
I will be able to tell if I can navigate around vb.net 2010 express with
the script active, the keyboard OnKeyUp or OnKeyProcessedUp active and if the
Keyboard doesnt lock up.
Also, I am not sure I will be able to use the shared objects from my
external script.
I'll have to take another look at it.
Which method in the SharedObject's code are you thinking might help?
Perhaps I can duplicate it in vb.net.
Anyway, I will run the test you described and do some reading about the
SharedObject file to see if I might use it but I don't think so from an
external script.
This is all getting to be a major headache compared to working in UIA and
native Microsoft code blocks.
Too bad there is no easy and safe UIA way to access the keyboard input
except low level hooking which is frought with potential problems.
Anyway, let me know which methods in SharedOnbjects you are thinking about
and I will read the code base for them to see what they are doing.
Rick USA
From: BT
To: [email protected]
Sent: Tuesday, June 12, 2012 8:04 AM
Subject: Re: WOM Seems Flawed for Keyboard Input Handling
Hi Rick,
The WMI Async is not coming through, that is a fact. It is needed in
order to do real time events, without it, you will not have anything work.
Granted this is inside WMI, but that is what is happening.
Now, when looking at your code, you do need a Queue method or, an
event monitor, polling device placed in your program. A Queue works nice since
it is outside the process but, no Queue for VB outside ow the WE model.
So, the other way is to do an event polling, but, there goes that
Async event being blocked problem.
In other languages such as Python you do have a bubble through event
to allow those event to go beyond the present event.
The semisyncronouse and syncronous stall the program for you have to
do a loop or an event poll. But since the Async event is not coming through no
polling is going to work.
Have you tried your program without doing any error log or file
processes? Just do something like send a speech method alert out when you have
triggered the key up event and see if just that little process also locks up
the keyboard. In other words take out eveything and just ad Speak " Key up! "
and see if it works then.
Do the invoke for the shared objects as I had shown you Aaron's
example of several months ago and see if it works through that as well.
Bruce
Sent: Tuesday, June 12, 2012 5:37 AM
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
