Hi Rick,
I think you will find that you must be totally out of the key event. The
keyprocess is needed to insure you are in fact out of the key itself. The WE
object model warns you of that.
In other words Rick, do not trigger a process, an app, a function until you
are away from the key event, for unpredictable results will happen, including
locking up your computer.
So, I make sure the key is back up, not in progress, so all future stuff
happens after your key is all done notifying the system...
Like the old days, too many CPU stacks being used, and some get filled, and
the rest is a nicely locked up computer.
So, my simple example is a good way to go, so you know you are out of the
key itself...
Bruce
Sent: Thursday, May 24, 2012 8:01 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Thanks Bruce. I'll check it out but the layout of the KeyProcessedUp in the
WE Docs sounds like it should watch for the specified key combination anytime
and trigger the Event Handler Sub whenever, wherever, that key combination is
pressed.
That said, perhaps WE does not know to watch for the Key up form of the
handler unless a corresponding Key Down form has occured. That isnt how keyUp
and KeyDown events work from what I know about key up and key down event
programming in .net but I didnt design the GW orObject Model so I'll spend the
time to read your code base and try to set something up to test your suggestion.
What about the fact that when I use a handler and the sub fires that the
screen does not go dark as it does when I do not use a handler and press
theShift-Escape key combo?
I thought the KeyProcessed events had no impact on the underlying Target
Application unless some specific action was specified in the EventHandler sub.
I'll just have to set up your method to see if I can get the KeyProcessedUp
event to fire and see if that makes any diference.
Thanks Again Bruce:
Rick USA.
----- Original Message -----
From: BT
To: [email protected]
Sent: Wednesday, May 23, 2012 10:40 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
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
