getting a return value from setTimeout()

peirix · November 25th, 2008, 08:42 AM

Is there a way of getting the return value from the function called within a setTimeout?

Something like this would have been great:
var timer = setTimeout("emailOutput = createEmail()", 50);

joefawcett · November 25th, 2008, 09:24 AM

No, the function hasn't run yet so the scenario doesn't make sense. Tthe return value is an id that can be used by cancelTimeout() to cancel the operation. To do what you want you could have emailOutput as a global variable that can be read after the delay has occurred.

--

Joe (Microsoft MVP - XML)

Old Pedant · November 25th, 2008, 11:13 PM

I could be wrong, Joe, but I think the answer you gave was really "yes."

Yes, the return value from createEmail( ) really is placed into that emailOutput variable.

But I suspect that the confusion peirix had/has is that he/she was expecting the value to be *immediately* available. That is:

Code:

    var timer = setTimeout("emailOutput = createEmail()", 50);
    if ( emailOutput == something ) ...

And THAT is the part that can't work, as Joe said.

The value of emailOutput won't be available until the timeout actually triggers, 50 milliseconds (a lifetime, in computer terms) from now.

So, peirix, if you need to *DO* something with that returned value, you might want to do:

Code:

    setTimeout("doSomethingWithValueReturnedFrom( assignToVariableOptional = createEmail() )", 50);

No real reason to assign the result of the call to createEmail() to a variable, but you could.

peirix · November 26th, 2008, 03:55 AM

Thanks guys.

Then I guess I need to figure a way around assigning the value. The reason I need to have the timeout, is because I'm dynamically loading external scripts into a generated html-page. And the only way I could call functions inside them, is by using timeout (I'm guessing the reason is because they need time to be loaded into memory?).

But, yeah, Old, you were right. The reason I was confused, was of course the fact that I forgot how setTimeout worked, putting something on hold, and then jumping to the next line. For some reason, I was expecting it to linger at that line, until 50ms had passed.

Old Pedant · November 26th, 2008, 04:39 AM

But why can't you just do as I suggested:

Suppose your existing code is like this:

Code:

step1( );
setTimeout( "emailTimeout=createEmail()", 50 );
step3( ...which uses that emailTimeout value ... );

Okay, so just change it to:

Code:

step1( );
setTimeout( "step2( )", 50 );
return;

// and then have your step2 look like this:
function step2()
{
    emailTimeout=createEmail();
    step3( ...which uses that emailTimeout value ... );
}

That is, delay processing the result of the call to createEmail() until the call is indeed complete.

No???

joefawcett · November 26th, 2008, 05:47 AM

Or why can't you call the function after the document onload has fired? This should only occur after all scripts and images have been downloaded.

--

Joe (Microsoft MVP - XML)

peirix · November 27th, 2008, 05:32 AM

@Joe: Well, because the Javascript I'm using to add external js-files is inside the body-tag, which I guess would be fired after the document onload in the first place, right?

@OldPedant: Yeah, that's what I ended up doing. Thanks. Works like a charm.

Old Pedant · November 28th, 2008, 12:44 AM

Quote:

quote:because the Javascript I'm using to add external js-files is inside the body-tag, which I guess would be fired after the document onload in the first place, right?

Well, yes and no.

The NON-TIMEOUT code will clearly be executed before the <BODY ONLOAD> fires, but any code deferred via setTimeout may or may not have yet executed. Can't really predict, and I don't think you should rely upon what you find to be true in any one browser, as another browser could act completely differently on this.

So I think Joe is wrong about calling from ONLOAD, but even if he is right for some browser, it's not a good idea to count on it. Opinion.

joefawcett · November 28th, 2008, 03:58 AM

I'm often wrong but in this case I don't think so. What I meant was that any code run after the onload fires should, according to the standards and in both IE and Firefox, have access to all elements of the page including scripted functions.

--

Joe (Microsoft MVP - XML)

Old Pedant · November 28th, 2008, 06:22 PM

Oh, yeah. I read your answer differently than that.

Though, of course, you could use JS code to *add* elements to the page (either HTML or JS code), and that could occur at any time, including (for example) as the result of some user action long after the page has loaded.

Super silly example:

Code:

<html>
<head>
<script>
function showFoo( )
{
    var f = document.getElementById("Foo");
    if ( f == null ) alert("No such thing as Foo");
    else alert( f.innerHTML );
}
</script>
</head>
<body onLoad="showFoo( )">
<div id="Holder"></div>
<p>
Stuff here.
<p>
<script>
setTimeout( "document.getElementById('Holder').innerHTML = '<div id=Foo>This is Foo!</div>';", 5000 );
</script>
<a href="#" onClick="showFoo( ); return false;">showFoo</a>
</body>
</html>

But aside from stuff like that, yeah.