execution order of actions

Hi,

I would like to have two actions for one event. But I want the second
action to trigger when the first one action completes. Is it possible
to do this in javascript? I'm using the onclick event.

Thanks,
Roman

roman wrote:[color=blue]
> Hi,
>
> I would like to have two actions for one event. But I want the second
> action to trigger when the first one action completes. Is it possible
> to do this in javascript? I'm using the onclick event.
>
> Thanks,
> Roman[/color]

Sure it is. :) For example:

elem.onclick = function ()
{
myfunc_act1();
myfunc_act2();
}

As long as the first function isn't asynchronous, then it will execute
in the order provided.

Would a window popup count a an asynchronous action?

I am trying to combine two actions in one event -> onclick.

Action1 -> popupwindow1; select something; bring back to parent form;
Action2 -> popupwindow2; does something and displays message; click on
window close;

Is this possible? Right now I have two buttons and the users need to
click on both. I would like to combine them.

Thanks,
Roman

Roman

roman wrote:[color=blue]
> Hi,
>
> I would like to have two actions for one event. But I want the second
> action to trigger when the first one action completes. Is it possible
> to do this in javascript? I'm using the onclick event.
>
> Thanks,
> Roman[/color]

JavaScript doesn't have synchronized methods per se. Multiple function
calls on the same event are just being added to the event handler's
internal hash without any guarantee of an execution order.
Say (Gesko syntacs):
obj.addEventListener('click',f1,false);
obj.addEventListener('click',f2,false);
doesn't mean at all that in case of a click function f1() will be
called first and function f2() second (it may happen just opposite).
Also there is no a build-in way to ensure that f2() will not start
until f1() is finished.

There are different tricks to emulate the <synchronized> behavior in
JavaScript. The most simple one (though not always applicable) way is
to assign the function's return value to some bogus variable:
....
var foo = f1(); // pseudo-synchronized function
foo = f2(); // pseudo-synchronized function
....
It does not matter if f1() or f2() have no return value (so <foo> will
be set to undefined). The program will still wait for that undefined
value until the function exits - which is pretty close to the
synchronized behavior.

VK wrote:[color=blue]
> JavaScript doesn't have synchronized methods per se.[/color]

Since javascript is not multi-threaded, the concept of a 'synchronized'
method is entirely irrelevant.
[color=blue]
> var foo = f1(); // pseudo-synchronized function
> foo = f2(); // pseudo-synchronized function[/color]

Completely unnecessary.

f1();
f2();

will always be executed one after the other. There is never a chance that f2
will be executed before f1 exits.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

Matt Kruse wrote:[color=blue]
> f1();
> f2();
>
> will always be executed one after the other. There is never a chance that f2
> will be executed before f1 exits.[/color]

Where did you get this very... *strange* idea?

VK said the following on 11/14/2005 11:23 PM:[color=blue]
> Matt Kruse wrote:
>[color=green]
>>f1();
>>f2();
>>
>>will always be executed one after the other. There is never a chance that f2
>>will be executed before f1 exits.[/color]
>
>
> Where did you get this very... *strange* idea?[/color]

Probably from reality.
Have you tried testing it?

function f1(){
var k = 0;
for (i=0;i<100000;i++){
k++
}
alert('finished f1()')
}

function f2(){
alert('finished f2()')
}

f1();
f2();

Which alert comes first?

But personally, if I wanted to dictate that f2() didn't execute until
f1() was finished, it would be like this:

function f1(){
//f1 code here

f2()
}

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Randy Webb wrote:[color=blue]
> VK said the following on 11/14/2005 11:23 PM:[color=green]
> > Matt Kruse wrote:
> >[color=darkred]
> >>f1();
> >>f2();
> >>
> >>will always be executed one after the other. There is never a chance that f2
> >>will be executed before f1 exits.[/color]
> >
> >
> > Where did you get this very... *strange* idea?[/color]
>
> Probably from reality.
> Have you tried testing it?
>
> function f1(){
> var k = 0;
> for (i=0;i<100000;i++){
> k++
> }
> alert('finished f1()')
> }
>
> function f2(){
> alert('finished f2()')
> }
>
> f1();
> f2();[/color]

Waht kind of reality is that and what does it have to do with the
<synchronized> issue? Did you try:

function f1() {
f2()
}

function f2() {
// doing something quicklier
// or faster than f1
}

P.S. Just knocked on me that this is that Matt - AJAX library inventor.
I would suggest then to read asap about *piper* input / output streams
in Java - why are they, how are they implemented and how could one
mimic them in JavaScript. That would solve a great amount of the
reported/incoming instability issues.

> function f1() {[color=blue]
> f2()
> }
>
> function f2() {
> // doing something quicklier
> // or faster than f1
> }[/color]

Naturally it should be something like:

function f1() {
for (;foo<bar; foo++) {
f2();
}

function f2() {
// doing something quicklier
// or faster than f1
}

or:

function f1() {
// slow preparation of ARG
f2(ARG);
}

function f2(arg) {
// a quicklier handling of arg
// and calling callback function
f1();
}

or any other situation there a flagged piped stream is needed.
Otherwise you'll get hundreds and thusands of copies of the same
function trying to handle the same oblect (or file) and it's only a
question of time and system tolerance before it crashes.

VK wrote:
[color=blue]
> Did you try:
>
> function f1() {
> f2()
> }
>
> function f2() {
> // doing something quicklier
> // or faster than f1
> }[/color]

Execution control will not return to f1() until f2() has returned (else
the return value of f2() would not be properly defined). Therefore, f2()
can only do something "quicker or faster" than f1() if properties or
methods of the AOM/DOM are involved, if that. It certainly is not a
language issue.

You would have known if you had not only read and understood the
specification and references but tested thoroughly instead of
presenting wild, unqualified assumptions on your part as the truth.
Again.

PointedEars

> You would have known if you had not only read and understood the[color=blue]
> specification and references but tested thoroughly instead of
> presenting wild, unqualified assumptions on your part as the truth.
> Again.[/color]

<OFFTOPIC>

1. Thomas, *sometimes* you real name is Dick
2. I've shown the situation in my second post but you answered on the
first one (?)
3. Please stop making piss on each topic I participated - you are not a
dog on the walk.
4. Say something only if you have something to say - and only if it
helps to solve the OP problem.

</OFFTOPIC>

%-D

VK wrote on 15 nov 2005 in comp.lang.javascript:[color=blue]
> 1. Thomas, *sometimes* you real name is Dick[/color]

Many nice people are named Dick overhere in Europe,
so,
if you want to insult someone on this international usenet forum,
please do so properly.

Better still, keep to the subjects that are on-topic.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Evertjan. wrote:[color=blue]
> VK wrote on 15 nov 2005 in comp.lang.javascript:[color=green]
> > 1. Thomas, *sometimes* you real name is Dick[/color]
>
> Many nice people are named Dick overhere in Europe,
> so,
> if you want to insult someone on this international usenet forum,
> please do so properly.
>
> Better still, keep to the subjects that are on-topic.[/color]

Sorry... allowed to myself to loose my patience.

Sorry to all Dicks and even to Thomas.

Requested to remove this post from the thread (I would do it anyway).

Thanks to everyone who contributed to my question.

Since a window popup count a an asynchronous action, then I don't think
I can do what I want. I tried to simulate a button click on the second
button, but this also executes too soon.

Thanks again,
Roman

"VK" <schools_ring@yahoo.com> writes:
[color=blue]
> att Kruse wrote:[color=green]
>> f1();
>> f2();
>>
>> will always be executed one after the other. There is never a chance that f2
>> will be executed before f1 exits.[/color]
>
> Where did you get this very... *strange* idea?[/color]

From experience with the execution model of quite a lot of Javascript
enabled browsers?

All these implementations are single-threaded. Execution is event
based, with each event having its code run to completion before the
next event is processed.
If two functions are called like above, exeution of the first will
end before the second is called. The f1 function might start some timers
that will later cause events that executes other code, but that's
not part of the execution of f1.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen wrote:[color=blue]
> "VK" <schools_ring@yahoo.com> writes:
>[color=green]
> > att Kruse wrote:[color=darkred]
> >> f1();
> >> f2();
> >>
> >> will always be executed one after the other. There is never a chance that f2
> >> will be executed before f1 exits.[/color]
> >
> > Where did you get this very... *strange* idea?[/color]
>
> From experience with the execution model of quite a lot of Javascript
> enabled browsers?
>
> All these implementations are single-threaded. Execution is event
> based, with each event having its code run to completion before the
> next event is processed.
> If two functions are called like above, exeution of the first will
> end before the second is called. The f1 function might start some timers
> that will later cause events that executes other code, but that's
> not part of the execution of f1.[/color]

I was *wrong*. A desire to say something polemic overweighted the rule
"think, check, then post". And JavaScript is not Java (funally read the
relevant FAQ :-)

The only right idea I managed (?) to express is that the order in which
one adds multiple event handlers via addEventListener / attachEvent -
this order doesn't define the order in which these events handlers will
be called on event.

VK wrote:
[color=blue]
> The only right idea I managed (?) to express is that the order in which
> one adds multiple event handlers via addEventListener / attachEvent -
> this order doesn't define the order in which these events handlers will
> be called on event.[/color]

That is probably so with IE-proprietary attachEvent() method:

<http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/attachevent.asp>

| If you attach multiple functions to the same event on the same object, the
| functions are called in random order, immediately after the object's event
| handler is called.

It is not so with EventTarget::addEventListener():

<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces>

In fact, in my Firefox 1.0.7/Linux all event listeners are always executed
in order of addition:

var o = referenceToAhtmlElementObject; /* I used _window.document.body in
the JavaScript Panel of ContextMenu Extensions */

o.addEventListener(
"click",
function() { alert(1); },
false);

o.addEventListener(
"click",
function() { alert(2); },
false);

o.addEventListener(
"click",
function() { alert(3); },
false);

Clicking the element represented by the object referenced with `o' yields
"1", then "2", then "3", as expected.

What is important with EventTarget::addEventListener() and could have led
you to believe that the execution order of event listeners added with this
method is random, is that you should not omit the third argument and that
it makes a difference if the argument is `false' (bubbling only, comes
after all event listeners for child elements and others of the target
element) or `true' (capturing only, comes before all event listeners for
child elements and bubbling).

PointedEars

VK wrote:[color=blue][color=green]
> > The only right idea I managed (?) to express is that the order in which
> > one adds multiple event handlers via addEventListener / attachEvent -
> > this order doesn't define the order in which these events handlers will
> > be called on event.[/color][/color]

Thomas 'PointedEars' Lahn wrote:[color=blue]
> That is probably so with IE-proprietary attachEvent() method[/color]

Right. The test case below gives for IE 6.0 this sequence:

f2()
f3()
f1()

For FF 1.0.7 it gives the original assignment sequence:
f1()
f2()
f3()

So yes, random execution order seems to be a "feature" of attachEvent
only. But at least it's properly documented on MSDN.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">

<script type="text/javascript">
function init() {
var obj = document.getElementById('test');
/*@cc_on
@if (@_jscript)
with (obj) {
attachEvent('onclick',f1);
attachEvent('onclick',f2);
attachEvent('onclick',f3);
}
@else @*/
with (obj) {
addEventListener('click',f1,false);
addEventListener('click',f2,false);
addEventListener('click',f3,false);
}
/*@end @*/
}

function f1() {
alert('f1');
}

function f2() {
alert('f2');
}

function f3() {
alert('f3');
}

window.onload = init;
</script>

<style type="text/css">
body {background-color: #FFFFFF}
var {font: normal 10pt Verdana, Geneva, sans-serif;
color: #0000FF; text-decoration: underline;
cursor: hand; cursor:pointer}
</style>

</head>

<body>

<noscript>
<p><font color="#FF0000"><b>JavaScript disabled:-</b><br>
<i><u>italized links</u></i> will not work properly</font></p>
</noscript>

<p>
<var id="test">Test</var>
</p>

</body>
</html>

I have a problem i'm thinking might be related to execution order as
discussed in this thread. Save the code below as an html file, load it
in your browser, and click the link to run the test.

The idea is that i show a hidden DIV while a potentially long-running
function runs alerting the user that something is happening. Once the
function is done - the DIV is hidden again.

However, what happens is that the function runs - but the DIV never
displays.

But......if you un-comment out the window.alert statement - the DIV
will display.

Is this related to execution order - or something else?


<a href="javascript:jsFunction()">Run Test</a>

<div id="notification" style="display: none; background: black; font:
white"></div>

<script>
function jsFunction() {
document.getElementById("notification").innerHTML = "test
notification";
document.getElementById("notification").style.disp lay = "";
//window.alert("test");
var x = 0;
while (x<2099999) {
x++;
}
document.getElementById("notification").innerHTML = ""
document.getElementById("notification").style.disp lay = "none";
}
</script>

autigers20@gmail.com wrote:[color=blue]
> I have a problem i'm thinking might be related to execution order as
> discussed in this thread. Save the code below as an html file, load it
> in your browser, and click the link to run the test.
>
> The idea is that i show a hidden DIV while a potentially long-running
> function runs alerting the user that something is happening. Once the
> function is done - the DIV is hidden again.
>
> However, what happens is that the function runs - but the DIV never
> displays.
>
> But......if you un-comment out the window.alert statement - the DIV
> will display.
>
> Is this related to execution order - or something else?
>
>
>
> 
> <a href="javascript:jsFunction()">Run Test</a>
>
> <div id="notification" style="display: none; background: black; font:
> white"></div>
>
> <script>
> function jsFunction() {
> document.getElementById("notification").innerHTML = "test
> notification";
> document.getElementById("notification").style.disp lay = "";
> //window.alert("test");
> var x = 0;
> while (x<2099999) {
> x++;
> }
> document.getElementById("notification").innerHTML = ""
> document.getElementById("notification").style.disp lay = "none";
> }
> </script>
> [/color]

This is how it is being run. Initially your div is hidden. Then when
you call your jsFunction the following will happen. If alert is
uncommented, then your div will be shown, and all execution will be
blocked until you hit "Ok" on the alert. That is why you are able to
see it. However, when the alert is commented, then your div is shown
AND hidden during the same execution scope regardless of how big your
while loop is. That is why you are not able to see the div being
shown, since you are hiding it again.

autigers20@gmail.com wrote:[color=blue]
> Is this related to execution order - or something else?[/color]

Something else.

The document will not refresh itself (and show the div) until the javascript
execution ends.
If you want the notification div to display, you should run a function to
display it, and have that function call setTimeout to run another function
in, say, 10ms. Then the function will end, your change will be shown in the
browser, and the other function to do the real work will fire after 10ms.
Then, at the end of that function, hide the div again.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

autigers20@gmail.com wrote:[color=blue]
> I have a problem i'm thinking might be related to execution order as
> discussed in this thread.
> 
> <a href="javascript:jsFunction()">Run Test</a>
>
> <div id="notification" style="display: none; background: black; font:
> white"></div>
>
> <script>
> function jsFunction() {
> document.getElementById("notification").innerHTML = "test
> notification";
> document.getElementById("notification").style.disp lay = "";
> //window.alert("test");
> var x = 0;
> while (x<2099999) {
> x++;
> }
> document.getElementById("notification").innerHTML = ""
> document.getElementById("notification").style.disp lay = "none";
> }
> </script>
> [/color]

It is not connected with the execution order per se but it is connected
with *synchronized* methods (more exactly - with the absence of such)
in the standard ECMAScript.
Here we have two independent system: script context and browser
rendering engine. Script cannot directly manipulate the rendering
engine - it just places requests to change rendering options (like
style.display) and continues its execution. If immediately after that
the script goes in some overly intensive process (like your loop), the
rendering engine never gets enough time to refresh the page so it just
holds on that until the script will get less demanding for resources.
Your alert("Test") simply gives to the rendering engine the needed
micro-break to accomplish the pending refresh request.
As script and rendering engine are two independent system, my
pseudo-synchronization trick with bogus var will not work:

var foo = (document.getElementById("notif").style.display = "block");
// doesn't work

foo will immediately get its undefined value ("request to redraw the
page is being sent successbully") and script will continue.

You need the full pseudo-sync in your case. Something like:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">
<a href="javascript:void(jsFunction())">Run Test</a>

<div id="notif" style="display: none; background-color: black;
color:white"></div>

<script>
function jsFunction() {
syncFun1();
setTimeout('syncFun2()',500);
}

function syncFun1() {
document.getElementById("notif").style.display = "block";
document.getElementById("notif").innerHTML = "test notification";
}

function syncFun2() {
var x = 0;
while (x<2099999) {
x++;
}
syncFun3();
}

function syncFun3() {
document.getElementById("notif").innerHTML = "";
document.getElementById("notif").style.display = "none";
}
</script>

</body>
</html>

"Matt Kruse" <newsgroups@mattkruse.com> writes:[color=blue]
> Something else.
>
> The document will not refresh itself (and show the div) until the javascript
> execution ends.
> If you want the notification div to display, you should run a function to
> display it, and have that function call setTimeout to run another function
> in, say, 10ms. Then the function will end, your change will be shown in the
> browser, and the other function to do the real work will fire after 10ms.
> Then, at the end of that function, hide the div again.[/color]

Thank you for this information, as that is a topic I too was
wondering about lately ("when does the browser actually refresh?").

Arnaud

On 2005-11-17, autigers20@gmail.com <autigers20@gmail.com> wrote:
[color=blue]
> But......if you un-comment out the window.alert statement - the DIV
> will display.
>
> Is this related to execution order - or something else?[/color]

the browser only displays when javascript execution finishes.

use a timeout after showing the div to give the browser time to display it
then in the timeout function do the processing and hide the div.

--

Bye.
Jasen

execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

re: execution order of actions

Similar JavaScript / Ajax / DHTML bytes

/bytes/development

/bytes/it

/bytes/about