Actually, ignore what I said about StartTimer starting countdown at the precise point in the code it is invoked. It really is like queue with the added option of a time delay in firing off the callback.
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:[email protected]]
> Sent: Thursday, June 14, 2012 10:53 PM
> To: [email protected]
> 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:[email protected]]
> > > Sent: Thursday, June 14, 2012 8:19 AM
> > > To: [email protected]
> > > 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:[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
> > > > > > >
> > > > >
> > >
>

Reply via email to