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

Reply via email to