The GW-Scripting list is a discussion list for information regarding the development and use of Window-Eyes scripts. Any subscriber of the GW-Scripting list has the ability to post on-topic messages.
From:
"BT" <b2me@fltg.net>Subject:
Re: WOM Seems Flawed for Keyboard Input HandlingDate:
Tue, Jun 12, 2012 8:04:50 amThis is a multi-part message in MIME format.
------=_NextPart_000_0011_01CD4872.0A939C50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
------=_NextPart_000_0011_01CD4872.0A939C50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19222">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi Rick,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> So, the other way is to do an
event polling, but, there goes that Async event being blocked
problem.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> In other languages such as
Python you do have a bubble through event to allow those event to go beyond the
present event.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>
Bruce</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, June 12, 2012 5:37
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> WOM Seems Flawed for Keyboard
Input Handling</DIV>
<DIV><BR></DIV>
<DIV><FONT size=2 face=Arial>Hi Guys:</FONT></DIV>
<DIV><FONT size=2 face=Arial>I have just finished monitoring
OnKeyDown,OnKeyUp, OnKeyProcessedDown, OnKeyProcessedUp and got the same
results I always get.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>I then pulled the OnKeyDown and
OnKeyProcessedDown handlers out so only the OnKeyUp and OnKeyProcessedUp event
Handlers fired.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>The keyboard input essentially seems to lock
up.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial>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)?</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>It is sounding more and more like Bruce has found
a major bug in the WOM (WindowEyes Object Model) - I hope not
though.</FONT></DIV>
<DIV><FONT size=2 face=Arial>That or there may be a problem with the way WE
handles keyboard input related to external scripts.</FONT></DIV>
<DIV><FONT size=2 face=Arial>Thanks:</FONT></DIV>
<DIV><FONT size=2 face=Arial>Rick USA</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0011_01CD4872.0A939C50--
------=_NextPart_000_0011_01CD4872.0A939C50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
------=_NextPart_000_0011_01CD4872.0A939C50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19222">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi Rick,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> So, the other way is to do an
event polling, but, there goes that Async event being blocked
problem.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> In other languages such as
Python you do have a bubble through event to allow those event to go beyond the
present event.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> 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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>
Bruce</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, June 12, 2012 5:37
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> WOM Seems Flawed for Keyboard
Input Handling</DIV>
<DIV><BR></DIV>
<DIV><FONT size=2 face=Arial>Hi Guys:</FONT></DIV>
<DIV><FONT size=2 face=Arial>I have just finished monitoring
OnKeyDown,OnKeyUp, OnKeyProcessedDown, OnKeyProcessedUp and got the same
results I always get.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>I then pulled the OnKeyDown and
OnKeyProcessedDown handlers out so only the OnKeyUp and OnKeyProcessedUp event
Handlers fired.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>The keyboard input essentially seems to lock
up.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial>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)?</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>It is sounding more and more like Bruce has found
a major bug in the WOM (WindowEyes Object Model) - I hope not
though.</FONT></DIV>
<DIV><FONT size=2 face=Arial>That or there may be a problem with the way WE
handles keyboard input related to external scripts.</FONT></DIV>
<DIV><FONT size=2 face=Arial>Thanks:</FONT></DIV>
<DIV><FONT size=2 face=Arial>Rick USA</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0011_01CD4872.0A939C50--
