Event wanted after page is refreshed

S

Stefan Mueller

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
 
J

JR

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
 
J

JR

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.






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.
}
 
D

David Mark

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.
 
D

Dr J R Stockton

In comp.lang.javascript message <2b8192d5-88aa-45df-b72b-4b698a869c00@j1
4g2000yqm.googlegroups.com>, Sat, 26 Dec 2009 11:58:43, Stefan Mueller
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) {


Rather than use Date, would it not be better to do something like

Busy = true
CallLengthySortFunction()
Busy = false

and test Busy at the start of your onClick routines?

That does not address the re-draw time question.
 
S

Stefan Mueller

Rather than use Date, would it not be better to do something like

        Busy = true
        CallLengthySortFunction()
        Busy = false

and test Busy at the start of your onClick routines?

That does not address the re-draw time question.

Yes, it would be much better to do something like
Busy = true
CallLengthySortFunction()
Busy = false
But it does not work.

The 'CallLengthySortFunction()' locks the whole javascript engine so
that the onClick event is not executed before the
'CallLengthySortFunction()' has finished. If you click on a column the
onClick event is "cached" and first when the 'CallLengthySortFunction
()' has finished the onClick event gets executed and then 'Busy' is
set False and not True anymore.

That's the reason why I'm trying to do something with the time
function.

However, like you mentioned, even if your solution with 'Busy' would
work I still had the problem that 'Busy = false' (last javascript
command) is executed BEFORE the browser has redrawn (refreshed) the
table on the screen. That means that 'Busy' is False before the user
sees the new sorted table on the screen and that he already can click
on another column before the newly sorted table is displayed.

I need any possibility, any event where I can execute the command
'Busy = false' or in my case to save the time just after the browser
is ready again (after the refresh which sometimes takes several
seconds).

Stefan
 
D

David Mark

There is no such question. ;)
Yes, it would be much better to do something like
  Busy = true
  CallLengthySortFunction()
  Busy = false

That's exactly the same. (?)
But it does not work.

The 'CallLengthySortFunction()' locks the whole javascript engine so
that the onClick event is not executed before the
'CallLengthySortFunction()' has finished. If you click on a column the
onClick event is "cached" and first when the 'CallLengthySortFunction
()' has finished the onClick event gets executed and then 'Busy' is
set False and not True anymore.

You are confused. "Cached" user actions are not going to do anything
until you are finished with the above execution. And there's a good
chance that the rendering will be updated on exiting the sort function
(though that is irrelevant). Post a test page that demonstrates your
problem as your descriptions so far can't be accurate.

And forget anything to do with timing. Such strategies are doomed to
fail (if not for you, then for some percentage of your users). ;)
 
S

Stefan Mueller

You are confused.  "Cached" user actions are not going to do anything
until you are finished with the above execution.  And there's a good
chance that the rendering will be updated on exiting the sort function
(though that is irrelevant).  Post a testpagethat demonstrates your
problem as your descriptions so far can't be accurate.

Here is a testpage:
http://test.seekware.ch/example.html

Please click once on 'Column 1' and after a few seconds the table is
sorted (just click 'Ok' to close the message box).
Click on 'Column 1' again and watch the message box. 'Busy' is false
and 'Difference' shows the time elapsed after the last sorting.
Now click 'Ok' and just again on 'Column 1' (before the sorting has
finished). Your click will be cached and just after the sorting has
finished the message box appears again. 'Busy' is false again and also
'Difference' shows the time elapsed (a couple of milliseconds) after
the last sorting again (this is the time the browser needs to refresh
the table).
And forget anything to do with timing.  Such strategies are doomed to
fail (if not for you, then for some percentage of your users).  ;)

I totally agree! I just thought that this could be the only
possibility. But if there's no possibility, no event where I can save
the time just after the browser is ready again it makes no sense.

To sum up: I'm looking for a solution to prevent clicking on a column
header while the table is sorting.
The only solution I figured out is to add the command 'alert("Sorting
done.");' at the end of the sort function because then the cached
mouse clicks get deleted. But I don't want to display such a message
box. Is there perhaps another way to delete these mouse clicks?

Stefan
 
J

JR

Here is a testpage:
 http://test.seekware.ch/example.html

Please click once on 'Column 1' and after a few seconds the table is
sorted (just click 'Ok' to close the message box).
Click on 'Column 1' again and watch the message box. 'Busy' is false
and 'Difference' shows the time elapsed after the last sorting.
Now click 'Ok' and just again on 'Column 1' (before the sorting has
finished). Your click will be cached and just after the sorting has
finished the message box appears again. 'Busy' is false again and also
'Difference' shows the time elapsed (a couple of milliseconds) after
the last sorting again (this is the time the browser needs to refresh
the table).


I totally agree! I just thought that this could be the only
possibility. But if there's no possibility, no event where I can save
the time just after the browser is ready again it makes no sense.

To sum up: I'm looking for a solution to prevent clicking on a column
header while the table is sorting.
The only solution I figured out is to add the command 'alert("Sorting
done.");' at the end of the sort function because then the cached
mouse clicks get deleted. But I don't want to display such a message
box. Is there perhaps another way to delete these mouse clicks?

The solution is using a flag ('busy') as a property of the sort
method:

function sort() {
if (arguments.callee.busy) { return; }
arguments.callee.busy = true;
// do the sort stuff.
arguments.callee.busy = false;
}
 
S

Stefan Mueller

The solution is using a flag ('busy') as a property of the sort
method:

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

Good idea but it doesn't work neither.

I added it to the testpage:
http://test.seekware.ch/example.html

'arguments.callee.busy' is also always false.

Stefan
 
J

Jorge

Good idea but it doesn't work neither.

I added it to the testpage:
 http://test.seekware.ch/example.html

'arguments.callee.busy' is also always false.

Stefan

Stefan,

All you need to do is to wrap the whole thing in a setTimeout
(sortingCode ,0); That will warrant a redraw *before* it executes.
Like this:

elem.onclick= function onclick () {
elem.onclick= null; //trash useless double-clicks
setTimeout(function () {

//Put your sorting code here.

elem.onclick= onclick;
}, 0);
};
 
D

David Mark


Okay. I glanced at it.
Please click once on 'Column 1' and after a few seconds the table is
sorted (just click 'Ok' to close the message box).

Yeah, it was more than a few on this machine. You have to break up that
process, using a timeout to fire each in turn. So there's no point in
worrying about how this version behaves.
Click on 'Column 1' again and watch the message box. 'Busy' is false
and 'Difference' shows the time elapsed after the last sorting.
Now click 'Ok' and just again on 'Column 1' (before the sorting has
finished). Your click will be cached and just after the sorting has
finished the message box appears again. 'Busy' is false again and also
'Difference' shows the time elapsed (a couple of milliseconds) after
the last sorting again (this is the time the browser needs to refresh
the table).

So what's the problem? And please lose the alerts as they can foul up
these sorts of tests.
I totally agree! I just thought that this could be the only
possibility. But if there's no possibility, no event where I can save
the time just after the browser is ready again it makes no sense.

I still don't see what your problem is.
To sum up: I'm looking for a solution to prevent clicking on a column
header while the table is sorting.

You can't prevent the user from clicking. You are in charge of your own
listners though. So it is up to you...
The only solution I figured out is to add the command 'alert("Sorting
done.");' at the end of the sort function because then the cached
mouse clicks get deleted.

That's an erroneous characterization, regardless of what you observed.
You really need to stop guessing.
But I don't want to display such a message
box. Is there perhaps another way to delete these mouse clicks?

There is no way to "delete" mouse clicks. You can, however, consult a
"busy" flag to determine whether to act on them or not. So in a couple
of sentences, what do you perceive the failure to be? And forget about
when the browser re-renders the column headers (that's a red herring).
 
D

David Mark

Jorge said:
Stefan,

All you need to do is to wrap the whole thing in a setTimeout
(sortingCode ,0); That will warrant a redraw *before* it executes.

As usual, you have no idea what you are talking about. This has
absolutely nothing to do with any so-called "redraw". Where do you get
this shit?

It's a simple click listener that needs to prevent re-entry in some
cases. How this has turned into a mystery is beyond me. If you can't
solve this one, you can't write anything for browsers.
 
D

David Mark

Hans-Georg Michna said:
Stefan,

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

It has nothing to do with that.
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.

Exactly. And, though irrelevant for this case, it should be mentioned
that re-flows are similarly predictable (they happen only on exiting
execution contexts).
Most browsers don't even render to screen, as long as any
JavaScript task is running, with the exception of Opera.

That's incorrect. They virtually all re-flow on exiting an execution
context. Though it makes no difference for this "problem" (can't stress
that enough), it is very useful to know this.

So if you see code that sets multiple styles and it calls a function to
set a single style in a loop (sound familiar?), you can figure on at
least one and maybe n re-flows during that loop. I see these patterns
all the time and adjusting them out usually leads to huge performance
increases (with very little effort invested), particularly for large and
complex DOM's (the norm, of course).
 
J

Jorge

(...)
It's a simple click listener that needs to prevent re-entry in some
cases. (...)

Mine not only does, but in addition warrants a redraw between sorts
(e.g. if the user clicked on a second column while the previous sort
was still running).
 
D

David Mark

Jorge said:
Mine not only does, but in addition warrants a redraw between sorts
(e.g. if the user clicked on a second column while the previous sort
was still running).

Not only does what?! And "warrants a redraw?" What do any of your
posts mean?
 
J

Jorge

You are saying that most browsers re-render to screen while some
JavaScript code is still to be or being executed? I haven't seen
that. What I see is that the browsers, except perhaps Opera,
don't do anything at all on screen until the JavaScript code
finishes execution or is killed because it ran for too long.

But I haven't done any exhausting tests on this. Has anybody
else here tested this thoroughly?

A reflow is not a redraw. There's (usually) many (more) reflows per
redraw. Reflows happen during normal JS execution, but redraws
(exception: Opera) don't.
 
D

David Mark

Hans-Georg Michna said:
You are saying that most browsers re-render to screen while some
JavaScript code is still to be or being executed?

What I said was they re-render on exiting execution contexts. So sure
there can still be JS to execute at that point.
I haven't seen
that.

Look again. :)
What I see is that the browsers, except perhaps Opera,
don't do anything at all on screen until the JavaScript code
finishes execution or is killed because it ran for too long.

I don't know what you think you see in Opera, but I can tell you for
sure that it is not special in this regard. And your observations are
incorrect.
But I haven't done any exhausting tests on this. Has anybody
else here tested this thoroughly?

There's no need to do any tests on it. It's a documented fact. It's
something you must deal with when designing UI widgets that run in
browsers. If you don't know how re-flows work, you can't hope to write
efficient (or consistent) widgets. It's been roughly the same game
since IE4. The problem is that there is a tsunami of bad examples and
associated misinformation out there on the Web, while most of the good
stuff runs behind corporate firewalls (side by side with lots more crap
of course).

Looking for unnecessary re-flows and memory leak patterns is usually the
first thing I am asked to do on a project. Most people know there are
problems in those areas that affect performance and/or waste resources,
but they don't know exactly what the problem is. ;)

But the OP's "problem" has nothing to do with any of this. That one
falls under too much execution in a listener (another common gaffe).
Break it up into steps with timeouts and never mind when the re-flows
happen.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top