Prev: Earn Money from Home as Part Time Job!
Next: FAQ Topic - Why do I get permission denied when accessing a frame/window? (2009-12-27)
From: Stefan Mueller on 12 Jan 2010 14:39
On Jan 12, 1:59 pm, JR <groups_j...(a)yahoo.com.br> wrote:
> > 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;

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
From: Jorge on 12 Jan 2010 21:12
On Jan 12, 8:39 pm, Stefan Mueller <seekw...(a)yahoo.com> wrote:
> On Jan 12, 1:59 pm, JR <groups_j...(a)yahoo.com.br> wrote:
>
> > > 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;
>
> 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);
};
--
Jorge.
From: David Mark on 13 Jan 2010 03:38
On Jan 11, 11:04 pm, Stefan Mueller <seekw...(a)yahoo.com> wrote:
> On Jan 7, 11:07 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > 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

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.

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

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).
From: David Mark on 13 Jan 2010 03:46
Hans-Georg Michna 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,
>
> 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).
From: Jorge on 13 Jan 2010 03:59
On Jan 13, 9:40 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> (...)
> 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).
--
Jorge.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Earn Money from Home as Part Time Job!
Next: FAQ Topic - Why do I get permission denied when accessing a frame/window? (2009-12-27)