Hi Matt, Yes, you have a pretty good understanding of it all. Yes, queue does seem to preserve the order of execution, but the documentation I don't think promises you that.
StopTimer just cancels the scheduled event altogether; it doesn't cause it to stop counting and execute right now (there's no way in a single command to stop the counting and cause something to execute immediately). And finally, the order of execution is not preserved when you start using StartTimer; take the example below: startTimer 10, "goodBye" startTimer 1, "hello" In the above lines, the sub hello will be executed first because its timer delay is smaller than the one for goodbye. hth, Chip > -----Original Message----- > From: MJ Williams [mailto:matthewjwilliams...@gmail.com] > Sent: Sunday, June 17, 2012 1:06 AM > To: gw-scripting@gwmicro.com > Subject: RE: connecting and disconnecting events and callbacks > > Thanksk Chip. I've just had a play with the Queue function. > from what I gather it triggers the callback immediately after > control has run through the sub or function within which it's > called. it would seem, and correct me if I'm wrong, that no > matter where in the sub the call to Queue is made, the order > of execution remains intact. > Here is a code frag to demonstrate this: > > ' start vbs code > set oHotkey = Keyboard.registerHotkey ( "control-Shift-2", "trigger" ) > > sub trigger ( ) > Queue "goodBye" > Speak "Hello" > end sub > > sub goodBye () > Speak "Good bye" > end sub > > ' end vbs code > The result is that hello is spoken out before good bye, even > though intuitively it should have been the other way around. > > Does the role of StopTimer go beyond putting the breaks on > the countdown started by StartTimer? > > Finally, just to be sure, startTimer and queue are identical > in so far as their general effect on the order of execution > goes, except that StartTimer let's you choose how long to > wait (starting at the precise point in the code) before it > invokes the callback. Correct? > > Regards > Matt > > At 17:43 16/06/2012, you wrote: > >Sorry for the delay Matt in responding. > > > >The TickCount Bruce mention works fine for timing things in > milliseconds. > >Sometimes though you may want to work in units you or the > user is more > >familiar with. > > > >VBScript has a built-in function called Now() which returns the date > >and time. There are two additional functions DateDiff, and DateAdd, > >which allow you to add or subtract other date-time variables or > >constants, and get returned whatever units you want; these can be > >seconds, or days, or months, or whatever. And, you can add > or subtract > >the same units and get another date-time variable. I tend > to use these > >and make the units be seconds when I'm working with timing things. > > > >Your other issue, when in an event handler, it's advised > that your code > >runs for as short a time as is possible; this means > specifically doing > >no user I/O such as speaking or reading or writing to a > file. Doing so > >might hang WE or cause some Windows feature to time out. This is > >especially true in the event handler calls for a function > such as the onKeyUp and down events. > > > >So, the answer is to use a queue command or a startTimer command to > >delay the execution of another sub or function to do the operations > >which may take more time. StartTimer allows you to specify > how long to > >wait before executing the sub, and the queue command just says "when > >you're done here ...". It's almost as if you were able to use a > >separate thread when you make use of these commands, but > they do not in > >fact use threads, they simply wait until the VBScript > interpreter for your thread is free. > > > >hth, > > > >Chip > > > > > > > -----Original Message----- > > > From: MJ Williams [mailto:matthewjwilliams...@gmail.com] > > > Sent: Thursday, June 14, 2012 10:53 PM > > > To: gw-scripting@gwmicro.com > > > Subject: RE: connecting and disconnecting events and callbacks > > > > > > Thanks chip. Could you elaborate on the use of the timer function > > > please? > > > I agree with you on the call to connectEvent for OnKeyUp. > I suppose > > > I was being a tad lazy in wanting a quick and dirty way out of a > > > little paradox I'd created for myself. > > > If the call is made from within trigger, then OnKeyUp is > triggered > > > by > > > Control-Shift-2 (or one of the two modifying keys > whichever released > > > first) returning to the neutral up position and therefore causing > > > the script to return an error for pressing the wrong key or keys. > > > Remember the only keys allowed are 0 to 9 and any other key will > > > trigger an error. maybe I could use a flag and a > conditional choice > > > to address the issue. > > > > > > Could you also explain the benefits of the queue function > in regards > > > to invoking the speak method in this instance please? > > > Regards > > > Matt > > > > > > At 02:49 15/06/2012, you wrote: > > > >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 > > > > > > > > > > > > > > > > > > > > > > > > >
