Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12004 > unrolled thread

How to write a browser based timer

Back to article view | Back to comp.lang.javascript

Contents

  How to write a browser based timer " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2012-02-21 15:50 -0500
    Re: How to write a browser based timer Scott Sauyet <scott.sauyet@gmail.com> - 2012-02-21 13:04 -0800
      Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-21 13:45 -0800
        Re: How to write a browser based timer "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-02-21 22:40 +0000
          Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-21 15:04 -0800
            Re: How to write a browser based timer "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-02-21 23:27 +0000
              Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-21 16:08 -0800
                Re: How to write a browser based timer "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-02-22 15:41 +0000
                  Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-22 09:19 -0800
                    Re: How to write a browser based timer "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-02-22 21:55 +0000
                      Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-22 15:01 -0800
          Re: How to write a browser based timer RobG <rgqld@iinet.net.au> - 2012-02-21 18:18 -0800
            Re: How to write a browser based timer Dr J R Stockton <reply1208@merlyn.demon.co.uk> - 2012-02-23 19:31 +0000
              Re: How to write a browser based timer Gene Wirchenko <genew@ocis.net> - 2012-02-23 16:38 -0800
                Re: How to write a browser based timer Dr J R Stockton <reply1208@merlyn.demon.co.uk> - 2012-02-25 20:29 +0000
                  Re: How to write a browser based timer "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-02-26 23:02 +0000
        Re: How to write a browser based timer Dr J R Stockton <jrs@merlyn.demon.co.uk> - 2012-02-22 18:51 +0000
      Re: How to write a browser based timer " Cal Who" <CalWhoNOSPAM@roadrunner.com> - 2012-02-23 10:23 -0500
        Re: How to write a browser based timer Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-23 22:13 +0100
          Re: How to write a browser based timer Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-24 09:41 +0100

#12004 — How to write a browser based timer

I need to know what to read about.

I want to write a browser based timer such that when one presses some key it 
starts incrementing and pressing another key pauses it.

HTML to be on the same  machine as the browser.

Timer to display minutes and seconds. (an hour max)

At each press the timer continues to count up from the last time it was 
paused.

What I need to know is what would be an appreciated language to study.

Is Javascript the way to go?

Must run on MAC or PC.

I have some programming experience and given a direction can probably learn 
what I need to do this.

Any examples of something close anywhere?

Thanks for any helpful direction comments.

[toc] | [next] | [standalone]

#12005

" Cal Who" wrote:
> I need to know what to read about.
>
> I want to write a browser based timer such that when one presses some key it
> starts incrementing and pressing another key pauses it.
> [ ... ]
>
> What I need to know is what would be an appreciated language to study.
>
> Is Javascript the way to go?

I assume you mean "appropriate language".

You can certainly do what you want with Javascript.  And it shouldn't
be difficult.

You need to look at three features of Javascript:

    - Keyboard Events, to listen for the keystrokes that matter
    - setTimeout or setInterval to occasionally check the time
    - DOM manipulation to display the results

Alternately, you can probably search the web for Javascript stopwatch
implementations and find one that either does exactly what you want or
could easily be modified to do so.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#12008

On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

[snip]

>I assume you mean "appropriate language".
>
>You can certainly do what you want with Javascript.  And it shouldn't
>be difficult.
>
>You need to look at three features of Javascript:
>
>    - Keyboard Events, to listen for the keystrokes that matter
>    - setTimeout or setInterval to occasionally check the time
>    - DOM manipulation to display the results
>
>Alternately, you can probably search the web for Javascript stopwatch
>implementations and find one that either does exactly what you want or
>could easily be modified to do so.

     Are they very accurate?

     Pause a second, update, then repeat will be inaccurate because of
the execution time being indeterminate.

     Following the clock will be somewhat more CPU-intensive.

     Assuming it exists, what is the third way that works well?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12011

Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:

> On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
> <scott.sauyet@gmail.com> wrote:
> 
> [snip]
> 
>>I assume you mean "appropriate language".
>>
>>You can certainly do what you want with Javascript.  And it shouldn't
>>be difficult.
>>
>>You need to look at three features of Javascript:
>>
>>    - Keyboard Events, to listen for the keystrokes that matter
>>    - setTimeout or setInterval to occasionally check the time
>>    - DOM manipulation to display the results
>>
>>Alternately, you can probably search the web for Javascript stopwatch
>>implementations and find one that either does exactly what you want or
>>could easily be modified to do so.
> 
>      Are they very accurate?
> 
>      Pause a second, update, then repeat will be inaccurate because of
> the execution time being indeterminate.
> 
>      Following the clock will be somewhat more CPU-intensive.

Not at all.

During run, display every [say] 200ms: 
    actualTime - lapStartTime + endCountLastLap 

During pause, display static:
    display endCountLastLap

Reset:
   endCountLastLap = 0
   setPause


> 
>      Assuming it exists, what is the third way that works well?
> 
> Sincerely,
> 
> Gene Wirchenko



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12012

On 21 Feb 2012 22:40:08 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:

[snip]

>>      Following the clock will be somewhat more CPU-intensive.
>
>Not at all.

     I am thinking yes, it will be more intensive, because the
updating must be more often to avoid having jerky output.  If the hit
is still not that much, well and good.

     (I am leery of anything approaching busy wait, because it can
really suck up the CPU time.)

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12013

Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

> On 21 Feb 2012 22:40:08 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
>>Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:
> 
> [snip]
> 
>>>      Following the clock will be somewhat more CPU-intensive.
>>
>>Not at all.
> 
>      I am thinking yes, it will be more intensive, because the
> updating must be more often to avoid having jerky output.  If the hit
> is still not that much, well and good.

200ms is enough, please try it out,
but even if it were each 50ms,
the CPU use would be do very-very-very low.

No incrementing is done, just new Date() and some adding,
and a DOM-innerHTML write.

>      (I am leery of anything approaching busy wait, because it can
> really suck up the CPU time.)

What is "busy wait"??

setTimeout() does not take cpu-time until it fires at the end, 
since it is just an added task at the general CPU-interrupt stack,
if that is what you mean. This task runs anyway on each machine's OS.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12015

On 21 Feb 2012 23:27:08 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

[snip]

>>      (I am leery of anything approaching busy wait, because it can
>> really suck up the CPU time.)
>
>What is "busy wait"??

     Busy wait is when a process consumes CPU time to implement a
wait.  One can delay with a for loop (busy wait) or a call to sleep()
(not busy wait).

>setTimeout() does not take cpu-time until it fires at the end, 
>since it is just an added task at the general CPU-interrupt stack,
>if that is what you mean. This task runs anyway on each machine's OS.

     Well, there is a loop being executed over and over.  That is why
my comment about approaching busy wait.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12047

Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

> On 21 Feb 2012 23:27:08 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
> [snip]
> 
>>>      (I am leery of anything approaching busy wait, because it can
>>> really suck up the CPU time.)
>>
>>What is "busy wait"??
> 
>      Busy wait is when a process consumes CPU time to implement a
> wait.  One can delay with a for loop (busy wait) or a call to sleep()
> (not busy wait).

Inconsequenttial in the case of setTimeout()

>>setTimeout() does not take cpu-time until it fires at the end, 
>>since it is just an added task at the general CPU-interrupt stack,
>>if that is what you mean. This task runs anyway on each machine's OS.
> 
>      Well, there is a loop being executed over and over.  That is why
> my comment about approaching busy wait.

You are WRONG in the case of Javascript [yes, we know Thomas] and 
setTimeout().

There is NO wait-loop here, Javascript execution finishes.

A new Javascript execution is triggered by the CPU-interrupt routine, in 
itself an interrupt of a loop on the microcode level, but one that must run 
anyway, since the CPU is only idle if the machine is switched of. 

Even waitloops in other compilers [or interpreters?] should use a short 
sleeps in the loop to minimize CPU cycle-grabbing, Javascript has no need 
for wait loops.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12050

On 22 Feb 2012 15:41:57 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

[snip]

>>      Well, there is a loop being executed over and over.  That is why
>> my comment about approaching busy wait.
>
>You are WRONG in the case of Javascript [yes, we know Thomas] and 
>setTimeout().
>
>There is NO wait-loop here, Javascript execution finishes.

     I stated that there was a loop, not that there was a wait-loop.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12067

Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:

> On 22 Feb 2012 15:41:57 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net> wrote:
> 
>>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:
> 
> [snip]
> 
>>>      Well, there is a loop being executed over and over.  That is why
>>> my comment about approaching busy wait.
>>
>>You are WRONG in the case of Javascript [yes, we know Thomas] and 
>>setTimeout().
>>
>>There is NO wait-loop here, Javascript execution finishes.
> 
>      I stated that there was a loop, not that there was a wait-loop.

Same thing, you are wrong in thinking that, there is no loop made.

In other worde sthere is no polling to see if the right time has come,
the right time is when the O.S. interupt fires.

There is no Javascript execution till triggered by the operating system,
so there are no CPU-cycles used by the programme.


> [snip]
> 
> Sincerely,
> 
> Gene Wirchenko
> 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12071

On 22 Feb 2012 21:55:09 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:
>
>> On 22 Feb 2012 15:41:57 GMT, "Evertjan."
>> <exjxw.hannivoort@interxnl.net> wrote:
>> 
>>>Gene Wirchenko wrote on 22 feb 2012 in comp.lang.javascript:
>> 
>> [snip]
>> 
>>>>      Well, there is a loop being executed over and over.  That is why
>>>> my comment about approaching busy wait.
>>>
>>>You are WRONG in the case of Javascript [yes, we know Thomas] and 
>>>setTimeout().
>>>
>>>There is NO wait-loop here, Javascript execution finishes.
>> 
>>      I stated that there was a loop, not that there was a wait-loop.
>
>Same thing, you are wrong in thinking that, there is no loop made.

     Sure there is.  The sequence that sets the timeout is repeatedly
executed.

>In other worde sthere is no polling to see if the right time has come,
>the right time is when the O.S. interupt fires.
>
>There is no Javascript execution till triggered by the operating system,
>so there are no CPU-cycles used by the programme.

     I know that.  That is what makes it not a busy-wait.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12018

On Feb 22, 8:40 am, "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
> Gene Wirchenko wrote on 21 feb 2012 in comp.lang.javascript:
> > On Tue, 21 Feb 2012 13:04:24 -0800 (PST), Scott Sauyet
> > <scott.sau...@gmail.com> wrote:

 [snip]

> >>Alternately, you can probably search the web for Javascript stopwatch
> >>implementations and find one that either does exactly what you want or
> >>could easily be modified to do so.
>
> >      Are they very accurate?

They should be based on the system clock, so should have equivalent
accuracy. More import is whether the stopwatch will update at the
appropriate time, which is a function of system load at the time the
function is scheduled to be called.

> >      Pause a second, update, then repeat will be inaccurate because of
> > the execution time being indeterminate.

If it is to update at a particular interval, the function should
calculate the milliseconds to the next full intervale and call the
function via setTimeout very soon after that (say 20 ms for a 1 second
timer). So the function only needs to run once per scond for a timer
with one second resolution.

If the resolution is 0.1 seconds, then schedule it to run say 10ms
after the next 100 ms interval so it runs about 10 times per second.
If system load is heavy and it misses an interval, it will appear to
skip but there is nothing you can do about that.


> >      Following the clock will be somewhat more CPU-intensive.
>
> Not at all.

The CPU use will be (roughly) a function of how often it is called, so
calling it less often should use less CPU.


--
Rob

[toc] | [prev] | [next] | [standalone]

#12113

In comp.lang.javascript message <3bf207fd-3d2f-40ab-95e7-9a1ed5a2ffd2@vh
10g2000pbc.googlegroups.com>, Tue, 21 Feb 2012 18:18:29, RobG
<rgqld@iinet.net.au> posted:

>
>If it is to update at a particular interval, the function should
>calculate the milliseconds to the next full intervale and call the
>function via setTimeout very soon after that (say 20 ms for a 1 second
>timer). So the function only needs to run once per scond for a timer
>with one second resolution.
>
>If the resolution is 0.1 seconds, then schedule it to run say 10ms
>after the next 100 ms interval so it runs about 10 times per second.
>If system load is heavy and it misses an interval, it will appear to
>skip but there is nothing you can do about that.

The answer, IMHO, is to use setInterval.  I'm not sure what happens if
one calls for an interval of one second and, after a while, keeps the
CPU very busy for a few seconds - does one get a burst of late
setInterval handler calls, or are some lost?  And what if, after
starting with setInterval, the machine is put into standby for a while?
But with setInterval, delays of substantially under a second in making
one handler call do not accumulate, as they would with simple repeated
setTimeout (Func, /const/)

To allow as best one can for such possibilities, the OP should NOT count
those handler calls for a measure of time, but should call new Date() to
get the time in milliseconds, from which simple arithmetic will get the
minutes, seconds, and maybe fractional part to display.


However, the valid objections to a wait loop along the lines of
        while (new Date()<EndTime) { ... }
are fewer than commonly thought.  A simple loop calculating the date of
Gregorian Easter Sunday for a full cycle or more takes a significant
while, but with at least some browsers the machine is still adequately
responsive.

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [next] | [standalone]

#12116

On Thu, 23 Feb 2012 19:31:27 +0000, Dr J R Stockton
<reply1208@merlyn.demon.co.uk> wrote:

[snip]

>The answer, IMHO, is to use setInterval.  I'm not sure what happens if
>one calls for an interval of one second and, after a while, keeps the
>CPU very busy for a few seconds - does one get a burst of late
>setInterval handler calls, or are some lost?  And what if, after
>starting with setInterval, the machine is put into standby for a while?
>But with setInterval, delays of substantially under a second in making
>one handler call do not accumulate, as they would with simple repeated
>setTimeout (Func, /const/)

     I suspect that the next interval is set as part of the previous
one firing:

     Catch that an interval has expired:
        Set next interval.
        Do what is supposed to be done with an fired interval.
     
>To allow as best one can for such possibilities, the OP should NOT count
>those handler calls for a measure of time, but should call new Date() to
>get the time in milliseconds, from which simple arithmetic will get the
>minutes, seconds, and maybe fractional part to display.

     Quite.

>However, the valid objections to a wait loop along the lines of
>        while (new Date()<EndTime) { ... }
>are fewer than commonly thought.  A simple loop calculating the date of
>Gregorian Easter Sunday for a full cycle or more takes a significant
>while, but with at least some browsers the machine is still adequately
>responsive.

     I do not agree.  On a system doing only one thing (as far as the
user is concerned?), that may be fine, but with multiple things going,
no.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12186

In comp.lang.javascript message <bnmdk7dbd04crei6qnaip7mosmesh8vkc8@4ax.
com>, Thu, 23 Feb 2012 16:38:03, Gene Wirchenko <genew@ocis.net> posted:

>On Thu, 23 Feb 2012 19:31:27 +0000, Dr J R Stockton
><reply1208@merlyn.demon.co.uk> wrote:
>
>[snip]
>
>>The answer, IMHO, is to use setInterval.  I'm not sure what happens if
>>one calls for an interval of one second and, after a while, keeps the
>>CPU very busy for a few seconds - does one get a burst of late
>>setInterval handler calls, or are some lost?  And what if, after
>>starting with setInterval, the machine is put into standby for a while?
>>But with setInterval, delays of substantially under a second in making
>>one handler call do not accumulate, as they would with simple repeated
>>setTimeout (Func, /const/)
>
>     I suspect that the next interval is set as part of the previous
>one firing:
>
>     Catch that an interval has expired:
>        Set next interval.
>        Do what is supposed to be done with an fired interval.

You may think that.  But I prefer to believe MDN; or, if something is
important to me, the results of tests.  St Luke: Chapter 10, Verse 37,
tail; consider the implications of
<https://developer.mozilla.org/en/window.setInterval> "Dangerous usage"


>>To allow as best one can for such possibilities, the OP should NOT count
>>those handler calls for a measure of time, but should call new Date() to
>>get the time in milliseconds, from which simple arithmetic will get the
>>minutes, seconds, and maybe fractional part to display.
>
>     Quite.
>
>>However, the valid objections to a wait loop along the lines of
>>        while (new Date()<EndTime) { ... }
>>are fewer than commonly thought.  A simple loop calculating the date of
>>Gregorian Easter Sunday for a full cycle or more takes a significant
>>while, but with at least some browsers the machine is still adequately
>>responsive.
>
>     I do not agree.  On a system doing only one thing (as far as the
>user is concerned?), that may be fine, but with multiple things going,
>no.

As above.  A sensible operating system, operating on adequate hardware,
will not allow a single user process to exclude everything else.  But
using timeouts is nicer.

There seems, though, to be a related fault in at least some browser
implementations :   while (true) alert("")   cannot be interrupted
except by killing at least the tab, maybe the window, maybe all windows
of that browser.

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike 6.05  WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#12192

Dr J R Stockton wrote on 25 feb 2012 in comp.lang.javascript:

> There seems, though, to be a related fault in at least some browser
> implementations :   while (true) alert("")   cannot be interrupted
> except by killing at least the tab, maybe the window, maybe all windows
> of that browser.

It can in Chrome.

"Take heed, keep on the alert(); for you do not know when the appointed 
time will come" [Mark 13:33, New American Standard Bible (1995)]

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12073

In comp.lang.javascript message <ht38k7pv0rr3vrinoj674dg70v5iic6tsq@4ax.
com>, Tue, 21 Feb 2012 13:45:13, Gene Wirchenko <genew@ocis.net> posted:

>
>     Pause a second, update, then repeat will be inaccurate because of
>the execution time being indeterminate.
>

If you had read <http://www.merlyn.demon.co.uk/js-date0.htm#TaI>, you
might have been able to write something more appropriate,

-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]

#12107

"Scott Sauyet" <scott.sauyet@gmail.com> wrote in message 
news:a44b4295-4c38-40c3-bc86-f63bd24d7720@b23g2000yqn.googlegroups.com...
>" Cal Who" wrote:
>> I need to know what to read about.
>>
>> I want to write a browser based timer such that when one presses some key 
>> it
>> starts incrementing and pressing another key pauses it.
>> [ ... ]
>>
>> What I need to know is what would be an appreciated language to study.
>>
>> Is Javascript the way to go?
>
> I assume you mean "appropriate language".

Yes - must be I wasn't careful with the spell checker.
You know what in your note below was most helpful?
The word "stopwatch"!
Somehow when I checked before posting that did not occur to me so I missed 
the most appropriate hits.

Thanks

>
> You can certainly do what you want with Javascript.  And it shouldn't
> be difficult.
>
> You need to look at three features of Javascript:
>
>    - Keyboard Events, to listen for the keystrokes that matter
>    - setTimeout or setInterval to occasionally check the time
>    - DOM manipulation to display the results
>
> Alternately, you can probably search the web for Javascript stopwatch
> implementations and find one that either does exactly what you want or
> could easily be modified to do so.
>
>  -- Scott 

[toc] | [prev] | [next] | [standalone]

#12111

Cal Who wrote:

> "Scott Sauyet" <scott.sauyet@gmail.com> wrote […]:
>> You can certainly do what you want with Javascript.  And it shouldn't
>> be difficult.
>>
>> You need to look at three features of Javascript:
>>
>>    - Keyboard Events, to listen for the keystrokes that matter
>>    - setTimeout or setInterval to occasionally check the time
>>    - DOM manipulation to display the results

JFTR, the rather simple and proper, because reliable, approach is to call 
clearTimeout() if a timeout was set before, then setTimeout(), on keyup.  
Checking for the time that has passed since the last keypress is _not_ 
reliable by comparison.

  var timeout = null;
  
  function clearMe (timeout)
  {
    if (timeout !== null)
    {
      window.clearTimeout(timeout);
    }
  } 

  _addEventListener(control, "keyup", function () {
    clearMe(timeout);

    timeout = window.setTimeout(function () {
      /* do something */

      clearMe(timeout);
    }, 42);
  }, false);

where _addEventListener() is a wrapper for control.addEventListener() with 
proprietary event-handler properties as fallback, like 
jsx.dom.addEventListener() in JSX:event.js [1].  For a more object-oriented 
implementation of the approach mentioned before, one might want to look into 
JSX:timeout.js [2], in particular jsx.dom.timeout.Timeout.prototype.run().


PointedEars
___________
[1] 
<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fevents.js>
[2] 
<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Ftimeout.js>
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#12128

Thomas 'PointedEars' Lahn wrote:

>   var timeout = null;
>   
>   function clearMe (timeout)
>   {
>     if (timeout !== null)
>     {
>       window.clearTimeout(timeout);

  timeout = null;

must be inserted here for the check to be reliable (as implemented with 
jsx.dom.timeout.Timeout).

>     }
>   }


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web