Event wanted after page is refreshed

Discussion in 'Javascript' started by Stefan Mueller, Dec 26, 2009.

  1. I've a html table which is sortable by clicking on the header of each
    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

    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 Mueller, Dec 26, 2009
    1. Advertisements

  2. Stefan Mueller

    JR Guest

    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;

    JR, Dec 27, 2009
    1. Advertisements

  3. Stefan Mueller

    JR Guest

    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, Dec 27, 2009
  4. Stefan Mueller

    David Mark Guest

    They all work about the same in that regard. They can re-flow on
    exiting execution contexts.
    David Mark, Dec 27, 2009
  5. In comp.lang.javascript message <2b8192d5-88aa-45df-b72b-4b698a869c00@j1
    4g2000yqm.googlegroups.com>, Sat, 26 Dec 2009 11:58:43, Stefan Mueller

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

    Busy = true
    Busy = false

    and test Busy at the start of your onClick routines?

    That does not address the re-draw time question.
    Dr J R Stockton, Dec 27, 2009
  6. Yes, it would be much better to do something like
    Busy = true
    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

    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

    Stefan Mueller, Jan 7, 2010
  7. Stefan Mueller

    David Mark Guest

    There is no such question. ;)
    That's exactly the same. (?)
    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). ;)
    David Mark, Jan 7, 2010
  8. Here is a testpage:

    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?

    Stefan Mueller, Jan 12, 2010
  9. Stefan Mueller

    JR Guest

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

    function sort() {
    if (arguments.callee.busy) { return; }
    arguments.callee.busy = true;
    // do the sort stuff.
    arguments.callee.busy = false;
    JR, Jan 12, 2010
  10. Good idea but it doesn't work neither.

    I added it to the testpage:

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

    Stefan Mueller, Jan 12, 2010
  11. Stefan Mueller

    Jorge Guest


    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);
    Jorge, Jan 13, 2010
  12. Stefan Mueller

    David Mark Guest

    Okay. I glanced at it.
    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.
    So what's the problem? And please lose the alerts as they can foul up
    these sorts of tests.
    I still don't see what your problem is.
    You can't prevent the user from clicking. You are in charge of your own
    listners though. So it is up to you...
    That's an erroneous characterization, regardless of what you observed.
    You really need to stop guessing.
    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).
    David Mark, Jan 13, 2010
  13. Stefan Mueller

    David Mark Guest

    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.
    David Mark, Jan 13, 2010
  14. Stefan Mueller

    David Mark Guest

    It has nothing to do with that.
    Exactly. And, though irrelevant for this case, it should be mentioned
    that re-flows are similarly predictable (they happen only on exiting
    execution contexts).
    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).
    David Mark, Jan 13, 2010
  15. Stefan Mueller

    Jorge Guest

    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).
    Jorge, Jan 13, 2010
  16. Stefan Mueller

    David Mark Guest

    Not only does what?! And "warrants a redraw?" What do any of your
    posts mean?
    David Mark, Jan 13, 2010
  17. Stefan Mueller

    Jorge Guest

    Too much thinking for you today... :)
    Jorge, Jan 13, 2010
  18. Stefan Mueller

    David Mark Guest

    No, too much time reading your ludicrous one-liners. :(
    David Mark, Jan 13, 2010
  19. Stefan Mueller

    Jorge Guest

    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.
    Jorge, Jan 13, 2010
  20. Stefan Mueller

    David Mark Guest

    What I said was they re-render on exiting execution contexts. So sure
    there can still be JS to execute at that point.
    Look again. :)
    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
    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
    David Mark, Jan 13, 2010
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.