From: Stefan Mueller on
I've a html table which is sortable by clicking on the header of each
column.
Because the sorting sometimes takes a couple of seconds I'd like to
prevent that the user can click the header of a column while the sort
function is running.

Here's my approach:
I do at the end of the sort function
sort_end_time = new Date().getTime();
and at the beginning of the sort function I check how much time has
passed after the sort function finished last time
if ((new Date().getTime() - sort_end_time) > 300) {

In this example you have to wait 300 milliseconds before you can sort
the next column. Therefore if you click on a column before the running
sort function has finished doing its job the value of '(new Date
().getTime() - sort_end_time)' is less than 300 milliseconds and the
clicked column will not get sorted. The problem I have now is that
when the last javascript command 'sort_end_time = new Date().getTime
();' is executed the browser needs some time to redraw (refresh) the
table on the screen. If the table has only a couple of rows then it
takes only some milliseconds but if the table has e.g. 2000 rows it
takes in IE more than 1000 milliseconds. Therefore the result of '(new
Date().getTime() - sort_end_time)' is always greater than 300
milliseconds.

Is there any possibility, any event where I can execute the command
'sort_end_time = new Date().getTime();' just after the browser is
ready again (after the refresh)? In my case the command 'sort_end_time
= new Date().getTime();' (the last command of the sort function) is
executed before the browser starts the redraw (refresh).

Stefan
From: Hans-Georg Michna on
On Sat, 26 Dec 2009 11:58:43 -0800 (PST), Stefan Mueller wrote:

>Is there any possibility, any event where I can execute the command
>'sort_end_time = new Date().getTime();' just after the browser is
>ready again (after the refresh)? In my case the command 'sort_end_time
>= new Date().getTime();' (the last command of the sort function) is
>executed before the browser starts the redraw (refresh).

Stefan,

check http://winhlp.com/node/633 for some basic thoughts about
the rendering to screen and its detection.

But you may be trying to kill a non-existent dragon. JavaScript
execution is single-threaded. No second JavaScript thread can
start before the current one has finished.

Most browsers don't even render to screen, as long as any
JavaScript task is running, with the exception of Opera.

Hans-Georg
From: JR on
On 26 dez, 17:58, Stefan Mueller <seekw...(a)yahoo.com> wrote:
> I've a html table which is sortable by clicking on the header of each
> column.
> Because the sorting sometimes takes a couple of seconds I'd like to
> prevent that the user can click the header of a column while the sort
> function is running.

This kind of sorting shouldn't take longer than a few milliseconds.
Maybe the code is not optimized for the browser in which you're
testing it.

> Here's my approach:
> I do at the end of the sort function
>   sort_end_time = new Date().getTime();
> and at the beginning of the sort function I check how much time has
> passed after the sort function finished last time
>   if ((new Date().getTime() - sort_end_time) > 300) {
>
> In this example you have to wait 300 milliseconds before you can sort
> the next column. Therefore if you click on a column before the running
> sort function has finished doing its job the value of '(new Date
> ().getTime() - sort_end_time)' is less than 300 milliseconds and the
> clicked column will not get sorted. The problem I have now is that
> when the last javascript command 'sort_end_time = new Date().getTime
> ();' is executed the browser needs some time to redraw (refresh) the
> table on the screen. If the table has only a couple of rows then it
> takes only some milliseconds but if the table has e.g. 2000 rows it
> takes in IE more than 1000 milliseconds. Therefore the result of '(new
> Date().getTime() - sort_end_time)' is always greater than 300
> milliseconds.
>
> Is there any possibility, any event  where I can execute the command
> 'sort_end_time = new Date().getTime();' just after the browser is
> ready again (after the refresh)? In my case the command 'sort_end_time
> = new Date().getTime();' (the last command of the sort function) is
> executed before the browser starts the redraw (refresh).

You can prevent a code from being called twice using the
'arguments.callee.done' old trick, e.g.:

function sort() {
if (!arguments.callee.done) { // checks the 'done' property of sort
().
return; // exit.
}
// If code doesn't return, do the sort stuff hereafter.
// But in the end of the sorting, don't forget to set
// arguments.callee.done = true;
}

Cheers,
JR
From: JR on
On 27 dez, 11:27, JR <groups_j...(a)yahoo.com.br> wrote:
> On 26 dez, 17:58, Stefan Mueller <seekw...(a)yahoo.com> wrote:
>
> > I've a html table which is sortable by clicking on the header of each
> > column.
> > Because the sorting sometimes takes a couple of seconds I'd like to
> > prevent that the user can click the header of a column while the sort
> > function is running.
>
> This kind of sorting shouldn't take longer than a few milliseconds.
> Maybe the code is not optimized for the browser in which you're
> testing it.
>
>
>
> > Here's my approach:
> > I do at the end of the sort function
> >   sort_end_time = new Date().getTime();
> > and at the beginning of the sort function I check how much time has
> > passed after the sort function finished last time
> >   if ((new Date().getTime() - sort_end_time) > 300) {
>
> > In this example you have to wait 300 milliseconds before you can sort
> > the next column. Therefore if you click on a column before the running
> > sort function has finished doing its job the value of '(new Date
> > ().getTime() - sort_end_time)' is less than 300 milliseconds and the
> > clicked column will not get sorted. The problem I have now is that
> > when the last javascript command 'sort_end_time = new Date().getTime
> > ();' is executed the browser needs some time to redraw (refresh) the
> > table on the screen. If the table has only a couple of rows then it
> > takes only some milliseconds but if the table has e.g. 2000 rows it
> > takes in IE more than 1000 milliseconds. Therefore the result of '(new
> > Date().getTime() - sort_end_time)' is always greater than 300
> > milliseconds.
>
> > Is there any possibility, any event  where I can execute the command
> > 'sort_end_time = new Date().getTime();' just after the browser is
> > ready again (after the refresh)? In my case the command 'sort_end_time
> > = new Date().getTime();' (the last command of the sort function) is
> > executed before the browser starts the redraw (refresh).
>
> You can prevent a code from being called twice using the
> 'arguments.callee.done' old trick, e.g.:
>
> function sort() {
>   if (!arguments.callee.done) { // checks the 'done' property of sort
> ().
>     return; // exit.
>   }
>   // If code doesn't return, do the sort stuff hereafter.
>   // But in the end of the sorting, don't forget to set
>   // arguments.callee.done = true;
>
> }
>
> Cheers,
> JR

Sorry, the correct sequence goes below:

function sort() {
if (arguments.callee.done) return;
arguments.callee.done = true;
// do the sort stuff.
arguments.callee.done = false; // in the end.
}

--
JR
From: David Mark on
On Dec 27, 5:11 am, Hans-Georg Michna <hans-
georgNoEmailPle...(a)michna.com> wrote:
> On Sat, 26 Dec 2009 11:58:43 -0800 (PST), Stefan Mueller wrote:
> >Is there any possibility, any event  where I can execute the command
> >'sort_end_time = new Date().getTime();' just after the browser is
> >ready again (after the refresh)? In my case the command 'sort_end_time
> >= new Date().getTime();' (the last command of the sort function) is
> >executed before the browser starts the redraw (refresh).
>
> Stefan,
>
> checkhttp://winhlp.com/node/633for some basic thoughts about
> the rendering to screen and its detection.
>
> But you may be trying to kill a non-existent dragon. JavaScript
> execution is single-threaded. No second JavaScript thread can
> start before the current one has finished.
>
> Most browsers don't even render to screen, as long as any
> JavaScript task is running, with the exception of Opera.
>

They all work about the same in that regard. They can re-flow on
exiting execution contexts.