Hi Rick,
Yes, that is very true as Steve points out. When I wrote my first screen
reader program on a DOS machine, all hooks were the actual keyboard interrupts
and screen and so forth. All done in assembly code or MASM.
The issue in this as GW has found out, is timing and speed to get out of
the hook as fast as you get in. For the slowing down will cause things such as
missed key inputs or, crashes which does cause the WE, GW, voice to die or
hang-up.
For the IRQ and keyboard interrupt is the only thing you can use to monitor
a keyboard for there is nothing else in the CPU processing that allows anything
else. For it is all timing.
The keyboard has to things going on, the interrupt alert, then the timing
of, counting of, all the keyboard code matrices. Those things have to have a
happy marriage and if one is slowed down, then timing issues evolve from it.
So, when doing the event, the timer IRQ is also monitored, that which
counts the ticks and when that is happy, and the keyboard interrupt occurs,
then you can slip in through the timer IRQ and get the data from the keyboard.
Which is now called the keyprocessed event.
As asked, if you want a flag set, or an event triggered, then place it out
there so we can resolve it. For you can place an event on the Queue to allow
something else to be triggered, which may be what you are looking for.
The keyboard interrupt is an IRQ, a very low level event, in the root of
all events. So, limited in what you can do in a very short time interval.
Bruce
Sent: Tuesday, June 05, 2012 6:45 AM
Subject: Re: Followup Threads WE, ExternalScript and vb.net 2010 Express
Hi:
I found out more about threading technicals related to using uia.
It appears that if you try and start a handler from within another handler
there can sometimes be problems.
Therefore it is recommended to put handlers on their own threads and pass
information back to the main thread to work with.
I have seen this mentioned for apps that try and use uia with themselves,
think for automation testing, but the set of articles I just read did not
mention whether the app was trying to monitor itself or if the app was trying
to monitor another Target Application.
This is what I ment in an earlier post about this stuff getting complicated.
There are major threading, process and Apartment issues and selecting the
correct threading and Apartment type for background threads is important to
analyze, monitor and control from what I have been reading.
Add to that that there is no way other than low level hooking to monitor
keyboard messages that I have found and this whole project is beginning to get
nasty from a simple quote scripting unquote viewpoint as we have come to
understand it using the WE Object Model provided by the GW guys.
So, final disposition of the original thread is that I will not use any
Keyboard monitoring of a Target App unless a GW Object Model feature will
provide it.
I just dont want to muck with low level hooks for security and performance
reasons.
Later and thanks for all the posts on this subject:
Rick USA
