Rick,
What is the goal for your keyboard hooking? I assume this is for your VS
2010 project?
Steve
On 5/23/2012 10:40 AM, BT wrote:
Hi Rick,
Sorry about not getting back sooner, but the data is not available is the
reason why I did what I did. But, you would have to look at each event, I think
you will find that the key event info is not ready until the key processed
event. I am just guessing but I think that is what I found out.
So, when doing such an event set a flag to indicate the key is down. Then
the next event, the key processed, gives you that data and the flag can be
reset and such to indicate that the event you are watching is in fact the one
that is giving the processed data...
So, when the keydown event happens, connect to the keyProcessedUp event
and when that happens collect the data captured by the key events, for they
will be ready at that point, and not some data from another event not related
to the one you are in fact watching.
The UnInstall program is involved a little because I am going down several
tree levels so many conditions are checked.
I reduced it down in the Trek game so it is a little more readable and
very little there.
So, just look at the very beginning of the MainDialogProc that does the
call back events in my Trek.vbs.
There is 2 subroutines for the processed event of the key which is set
using the connectevent at the beginning of the call back function.
See if that works for you.
Bruce
Sent: Wednesday, May 23, 2012 9:11 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Bruce:
It sounds like you set up a handler for the KeyProcessedDown event and
then, within that code, watch for the subsequent KeyProcessedUp event.
Before I spend hours slogging through allot of unfamiliar code is this
the case?
Can you tell me why you used both the KeyProcessedUp and the
KeyProcessedDown Event handlers instead of just the one that applied to your
situation?
Both event handlers have the same parameters so should work independently
unless I am missing something from the Docs.
Rick USA
Rick USA
From: BT
To: [email protected]
Sent: Wednesday, May 23, 2012 7:58 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Rick,
I think you will find that the data is not there until the key is
released, only a guess.
Look at my Uninstall program, and the addition to my Trek game. In
both .vbs files I watch for the key down and connect for the key up process. I
think you will find that data and such is not ready until the key processed up
happens.
Bruce
To: [email protected]
Sent: Wednesday, May 23, 2012 7:12 AM
Subject: KeyProcessedUp and KeyProcessedDown Events
Hi Guys:
In my external script while testing against the Target App vb.net 2010
Express:
The KeyProcessedDown event fires the target subroutine specified in the
AddressOf parameter.
The KeyProcessedUp does not.
Is the functionallity of these keys dependent on whether the Target
Application being scripted specifies the KeyUp or KeyDown Methods in the source
code or are the WE versions suppose to execute upon actual user interaction
with the Keyboard regardless of whether the programmer used the KeyDown or
KeyUp or KeyPressed methods?
Also:
When I do not use the OnKeyProcessedDown event
handlers the screen goes dark when I press Shift-Escape to close the
Solution Explorer.
The screen does not go dark when I cllose the Solution Explorer while
using the OnKeyProcessedDown Event Handler.
The OnKeyProcessedUp Event handler does not fire in any case - thus the
first question.
If I understand these events they should not impact the operation of the
Target Application being scripted so the screen should still go dark when the
Shift-Escape keys are pressed without doing any handling of passing keys
through to it, or am I wrong on that?
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
