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
