Hi Matt, Looks very nice!
I would use a queue command to do the speaking. Also, I'd connect to the key up at the same time you connect to key down, because these events occur so close together that I would be concerned waiting to connect to key up in the key down might just cause you to miss it. Finally, I see what you're doing with the timer code, but that's not valid VBScript; I suspect you're going back to jScript, so doesn't matter, but if you want to do date-time arithmetic, let me know and I'll post the code you'll need for VBScript. good luck, Chip > -----Original Message----- > From: MJ Williams [mailto:matthewjwilliams...@gmail.com] > Sent: Thursday, June 14, 2012 8:19 AM > To: gw-scripting@gwmicro.com > Subject: RE: connecting and disconnecting events and callbacks > > 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:matthewjwilliams...@gmail.com] > > > Sent: Wednesday, June 13, 2012 12:25 PM > > > To: gw-scripting@gwmicro.com > > > 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:matthewjwilliams...@gmail.com] > > > > > Sent: Tuesday, June 12, 2012 11:10 PM > > > > > To: gw-scripting@gwmicro.com > > > > > 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 > > > > > > > > >
