I can't help you with either unfortunately, I was just suggesting you try working with some other unmanaged code com object which has events as part of it's model.
Chip > -----Original Message----- > From: RicksPlace [mailto:[email protected]] > Sent: Wednesday, June 20, 2012 9:09 AM > To: [email protected] > Subject: Re: Followup Threads WE, ExternalScript and vb.net > 2010 Express > > Hi Chip: I did that some time ago. > I dont know if I posted it but noted that I had created it if > anyone was interested. > BT: Everything I have done has been just to use the > WindowEyes Keyboard.OnKeyDown and Keyboard.OnKeyUp event handlers. > That is standard WE Events of the Keyboard object - nothing > complicated or fancy. > All the talk about complicated things has been to try and > figure out why they dont work properly. > Trying to debug a COM process between managed code and > unmanaged code is indeed complicated and I dont really have > the tools to do it properly. > I will strip my project to bare bones and post it's code or > post the project itself with instructions if anyone is interested. > Now, do you just want the vb.net code or the entire vb.net > 2008 express project? > Which will be easier for you to work with?Rick USA Rick USA > ----- Original Message ----- > From: "Chip Orange" <[email protected]> > To: <[email protected]> > Sent: Tuesday, June 05, 2012 8:36 PM > Subject: RE: Followup Threads WE, ExternalScript and vb.net > 2010 Express > > > >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 > >> > > >
