Rick,
Yes; this stuff is complicated which is why we took such pains to design
a flexible and easy-to-use scripting interface for Window-Eyes. We are
interested in helping you further, but it's unclear what you are now
wanting to accomplish. Perhaps a list of specific goals would help iron
things out and, in turn, we can likely find a more straight-forward
solution.
Regards,
Steve
On 6/5/2012 6:45 AM, RicksPlace wrote:
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
--
Stephen Clower
Product support specialist & App Development
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
