Hi Rick,
This is what I sent you as a web page. Take a look at what the recommend
and go to the link to get the other links...
Bruce
http://msdn.microsoft.com/en-us/library/ms788709Note
This documentation is intended for .NET Framework developers who want to use the
managed UI Automation classes defined in the
System.Windows.Automation
namespace. For the latest information about UI Automation, see
Windows Automation API: UI Automation
.
Because of the way Microsoft UI Automation uses Windows messages, conflicts can
occur
when a client application attempts to interact with its own UI on the UI thread.
These conflicts can lead to very slow performance or even cause the application
to
stop responding.
If your client application is intended to interact with all elements on the
desktop,
including its own UI, you should make all UI Automation calls on a separate
thread.
This includes locating elements (for example, by using
TreeWalker
or the
FindAll
method) and using control patterns.
It is safe to make UI Automation calls within a UI Automation event handler,
because
the event handler is always called on a non-UI thread. However, when subscribing
to events that may originate from your client application's UI, you must make
the
call to
AddAutomationEventHandler
, or a related method, on a non-UI thread. Remove event handlers on the same
thread.
Sent: Saturday, June 23, 2012 7:56 AM
Subject: Re: External Script Keyboard Problems Review
Hi Rick,
Noting your last response, I sent you a page on threading and what
Microsoft recommends to call to insure the threading is done properly. I don't
know if you got that threading page but the subject line is threading and it
was a web page I sent you.
I think this entire issue is that you have to call each, monitor each,
event using a different thread for each because the timing is so fast and exact
that as you stated, a crash between them happens if both inside the same
thread. Microsoft warns you about that and I sent you the reason and solution.
So look at the threading page I sent and see what you can try to resolve
it.
Sincerely
Bruce
Sent: Saturday, June 23, 2012 7:35 AM
Subject: External Script Keyboard Problems Review
There have been allot of good suggestions on this topic.
I have tried allot of diferent approaches with no success so far from using
a Cursor Key to using AddHandlers against the Keyboard object and the Key
Object and even the Event as documented in an Excel article.
I have noted some things that may yet leave questions hanging from Bruce's
idea of a timing issue to storing the event handler variables which is done in
Chip's example and not in a vb.net application except where I defined a Delegat
to hold the address of the ffunctions to get executed when an OnKeyUp and
OnKeyDown are suppose to be fired.
I am currently ReReading all your posts for all the threads again to see if
I can pick up on anything I may not have tried and will set up an organized
document of ReAttempting solutions based on all your ideas.
You all have put allot of time into trying to help so the least I can do is
to ReEvaluate all ideas before giving up.
I'll post up in a week or so after carefully evaluating each test just to
let you all know if I got it working.
Thanks for all the suggestions:
Rick USA
