I have to agree with Steve Rick; I think you were heading off in needlessly complex directions, when WE will give you all the interface to keyboard monitoring which you could wish.
If you think you know of something in WE which is not working as documented, it would do everyone a much bigger favor if you would write a minimal example program to demonstrate this and send it to GW or post it here; it would be much more useful to everyone if you helped them find and fix such a problem. Just one more thought. Chip > -----Original Message----- > From: Stephen Clower [mailto:[email protected]] > Sent: Tuesday, June 05, 2012 7:47 AM > To: [email protected] > Subject: Re: Followup Threads WE, ExternalScript and vb.net > 2010 Express > > 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 >
