Hello Chip
Here's the VBScript version of the code in my last post.
' begin VBScript code
Option Explicit
Dim oHotkey
Dim hKeyDown
Dim hKeyUp
Dim elapsed
Set oHotkey = Keyboard.RegisterHotkey("Control-Shift-2", "trigger")
Sub trigger()
hKeyDown = ConnectEvent(Keyboard, "OnKeyDown", "OnKeyDown")
Speak "Enter secondary key"
End Sub
Function OnKeyDown(key, Modifier)
hKeyUp = ConnectEvent(Keyboard, "OnKeyUp", "OnKeyUp")
elapsed = Timer
If modifier = kmNone And (key >= vk_0 And key <= vk_9) Then
Speak "Bingo!"
Else
Speak "uh oh!"
End If
Disconnect hKeyDown
hKeyDown = Empty
OnKeyDown = kdDiscard
End Function
Function OnKeyUp(key, modifier)
elapsed = Timer - elapsed
Speak elapsed
Disconnect hKeyUp
hKeyUp = Empty
OnKeyUp = kdDiscard
End function
' end VBScript code
Regards
Matt
At 18:50 13/06/2012, you wrote:
Hi Matt,
#1: if you may need to interfere with a key, that is you may want to keep WE
or the Windows program from seeing the key (a very unusual need), then you
would use the onKeyDown and onKeyUp events (you must use them in pairs).
They let you do unusual things such as give the key to the Windows program
but keep WE from ever seeing it. They are available both for a specific key
(when used from the key object) and for all keys (when used from the
keyboard object).
If you only need to know that a certain key was pressed down, and then was
released back up, then you should avoid use of onKeyDown and onKeyUp because
you could interfear with the handling of the key, and you should use the
onKeyProcessedUp events instead (again, for a specific key from the key
object, or for all keys from the keyboard object). Here, in this case, I
think it's easier and better, if you have a specific key in mind, to
register a cursor key than to use these key events for down and up. A
cursor key in this case mans only a key which is meant to be seen by the
Windows Program as well as WE, it has nothing to do with arrow keys etc.
The example you asked about however is not a cursor key, because you don't
mean for some program to see it, you mean only for your app to see it, so it
is a "hot key" instead of a "cursor key".
#2: your event handler goes on as normal, and returns a value as normal,
which is acted upon as normal, even if you disconnect the event handler in
the middle of the processing. Disconnecting is just saying "don't send me
any more of these".
hth,
Chip
> -----Original Message-----
> From: MJ Williams [mailto:[email protected]]
> Sent: Wednesday, June 13, 2012 12:25 PM
> To: [email protected]
> Subject: RE: connecting and disconnecting events and callbacks
>
> Many thanks Chip. Before I send out a more refined version
> of the code, I've two questions:
> 1. What is the difference between the OnKey* and
> OnKeyProcessed* events? I have some understanding of the
> differences, or at least I think i do, though I'd be grateful
> for further elucidation.
>
> 2. What happens to the value returned by the event handler,
> and will the disconnection of the event from its handling
> function in any way affect the process? On the face of it my
> OnKeyDown handler's returning kdDiscard has the intended
> effect on the fate of the key value that triggers said event,
> with or without the Disconnect call,namely, the key is
> discarded whether the call comes before kdDiscard is returned
> or afterwards. Again, more behind-the-scenes info would be
> gratefully received.
>
> Regards
> Matt
>
> At 16:04 13/06/2012, you wrote:
> >Hi Matt,
> >
> >I don't read JS, but I did try to pick your questions out of
> the message:
> >
> >nothing happens immediately when you disconnect from an event; that
> >just means you will not have your event handler called any more to
> >handle those events, so it's fine to do inside of an event handler.
> >
> >If you want a double key hotkey, then I'd register the first
> key as a
> >hotkey. in the hotkey callback for the first key, I'd register the
> >second keys as hotkeys.
> > I'd also connect to the onKeyProcessedUp event in this
> first hotkey's
> >callback, and in the onKeyProcessedUp's callback I'd
> unregister all the
> >secondary hotkeys (so that as soon as any key was pressed after the
> >first hotkey, the secondaries would be unregistered, regardless of
> >whether it was one of them which was pressed or not).
> >
> >This doesn't answer the question as to what will happen if
> they press
> >something after the first hotkey which isn't one of your
> second keys;
> >you didn't say what you want to happen in that case. In the
> way I just
> >described, the first hotkey just gets ignored by WE and Windows, and
> >the second key, if not one of your secondary keys, will be
> processed by them.
> >If the second key is one of yours, then it too will be ignored by WE
> >and Windows.
> >
> >hth,
> >
> >Chip
> >
> >
> > > -----Original Message-----
> > > From: MJ Williams [mailto:[email protected]]
> > > Sent: Tuesday, June 12, 2012 11:10 PM
> > > To: [email protected]
> > > Subject: connecting and disconnecting events and callbacks
> > >
> > > Hello,
> > > I'm trying to create a two-stage or double-stroke hotkey, e.g.
> > > Insert-x followed by a series of options offered by keys 1 to 9.
> > > Here's a rough idea of how I am going about it in code at the
> > > moment:
> > > // start JS code
> > > 0: var conHandle = null;
> > > 1:
> > > 2 function test ( ) {
> > > 3 conHandle = ConnectEvent (Keyboard, "OnKeyDown", "OnKeyDown" )
> > > 4 }
> > > 5
> > > 6 function OnKeyDown (key, mod) {
> > > 7 if ( key == vk_1 ) {
> > > 8 Speak ("done");
> > > 9 Disconnect( conHandle );
> > > 10
> > > 11 return kdDiscard;
> > > 12 }
> > > 13 }
> > > // end js code
> > >
> > > A variant of this code runs as intended, even though the call to
> > > disconnect (at line 9) comes before the callback returns its
> > > disposition, and I would have thought that disconnecting the
> > > connecting event at that point would disrupt the returning of the
> > > key disposition. I would like to know exactly what goes
> on behind
> > > the scenes when a callback tied to an event of this kind
> is invoked.
> > > More specifically, where does the key disposition value
> returned by
> > > the callback end up, and what happens (at least in
> theory) when the
> > > disconnect method is invoked before the callback has completed
> > > execution?
> > >
> > > If anyone has a more elegant solution to my original idea
> I would be
> > > grateful for any pointers.
> > >
> > > Regards
> > > Matt
> > >
>
