setTimeout not executing form submit

Mic

Goal: delay execution of form submit

Code (Javascript + JScript ASP):

<%
Response.Write("<OBJECT ID='IntraLaunch' STYLE='display : none'
WIDTH=0 HEIGHT=0 CLASSID='CLSID:0AE533FE-B805-4FD6-8AE1-A619FBEE7A23'
CODEBASE='IntraLaunch.CAB#version=5,0,0,3'>")
Response.Write("<PARAM NAME='ImageLoc' VALUE='Null'>")
Response.Write("<PARAM NAME='ImageSrc' VALUE='Null'>")
Response.Write("<PARAM NAME='Run'
VALUE='F:\\Axys3\\Clarity\\report1.bat'>")
Response.Write("<PARAM NAME='RunParms' VALUE=''>")
Response.Write("<PARAM NAME='Display' VALUE=MAX'>")
Response.Write("</OBJECT>")
%>

<script>

function UpdateRec(theForm, rec) {

tmp_checked = 0;

tmp_login = theForm.login.value;
tmp_year = theForm.tmp_year.value;
tmp_quarter = theForm.tmp_quarter.value;
tmp_comm = theForm.comm.value;

if(theForm[rec].checked) {
tmp_checked = 1;
}

theForm.target = "MyFrame";
theForm.action = "qr_update.asp?axys=" + rec + "&tmp_quarter=" +
tmp_quarter + "&tmp_year=" + tmp_year + "&tmp_login=" + tmp_login +
"&tmp_checked=" + tmp_checked + "&tmp_comm=" + tmp_comm;
theForm.submit();
document.body.style.cursor = 'wait';
}

function GenerateReport(theForm, rec, do_checkbox) {

document.IntraLaunch.RunParms = rec;
IntraLaunch.ExecuteIt("Null");

if (do_checkbox) {
oldcomm = theForm.comm.value;
theForm.comm.value = "GSHOW";
theForm[rec].checked = true;
UpdateRec(theForm, rec);
theForm.comm.value = oldcomm;
}

tmp_year = theForm.tmp_year.value;
tmp_quarter = theForm.tmp_quarter.value;
theForm.target = "MyOtherFrame";
theForm.action = "generate.asp?quarter=" + tmp_quarter + "&year=" +
tmp_year + "&axys=" + rec;

var timer = setTimeout("document."+theForm.name+".submit()", 2000);
clearTimeout(timer);

//alert("GenerateReport form object name: " + theForm.name);
//document.updateform.submit();
}

background/explanation:

This is a task-status tracking web application. The purpose of this
code snippet is to automatically create two Axys reports as text
files, parse them into PDFs, and collate them into a third PDF, all on
the click of a button. GenerateReport is the method that's called
directly; the object declaration and UpdateRec are there for your
reference. The issue here is that it takes some time (a second or
two) to generate the text files via IntraLaunch, and I need to delay
the PDF operations (performed in generate.asp) until this is done.

The code itself is sound -- by uncommenting the last two lines,
everything functions smoothly, since the alert acts as a delay.

I have found that setTimeout is not executing the form submit at all:
I placed alerts in <body onload=> of both qr_update.asp and
generate.asp. The sans-setTimeout version pops an alert for each page,
but if I use setTimeout, I only get an alert for qr_update. I am
puzzled, though, because this seems to be the correct syntax for form
submission via setTimeout:
http://groups.google.com/groups?q=se...ft.com&rnum=10

Please help!

Thanks,
Michelle

Jul 23 '05 #1

Subscribe Post Reply

8698

Lee

Mic said:

var timer = setTimeout("document."+theForm.name+".submit()", 2000);
clearTimeout(timer);

setTimeout doesn't insert a delay.
It schedules some task to be performed after a specified delay.
Execution proceeds immediately to the next line.

Those two lines say:
1. Wait two seconds, and then submit the form.
2. Nevermind.

Jul 23 '05 #2

Mic

Yep, that fixed it.

1) I feel retarded
2) You're awesome -- thanks!!!!!

:-)

Jul 23 '05 #3

Thomas 'PointedEars' Lahn

Lee wrote:

Mic said:
var timer = setTimeout("document."+theForm.name+".submit()", 2000);
clearTimeout(timer);

setTimeout doesn't insert a delay.
It schedules some task to be performed after a specified delay.

Actually, if provided a string as first argument, setTimeout() schedules
that expression to be evaluated after a specified delay. If provided a
Function object reference instead, the function referred to is called,
using the third and following arguments of setTimeout() as arguments for
the function [JavaScript 1.2+/Gecko-DOM only; the IE-DOM does support
function references from v5.0 on, but not additional arguments to date
(IE 6.0 SP-1) -- setTimeout(alert, 2000, 42) yields an empty message box
in IE, but not in NN4+/Mozilla.]

However, the used expression is suboptimal as document.FormName is not a
standards compliant reference (i.e. not specified in W3C-DOM Level 1+).
Instead document.forms["FormName"] is specified there, thus the better
statement is either

var timer =
setTimeout("document.forms['"+theForm.name+"'].submit()", 2000);

or

var timer =
setTimeout(document.forms[theForm.name].submit, 2000);

Yet it would be much better to check (calling a user-defined method) if
there is document.forms[theForm.name].submit() before accessing it. For
the first variant, as used in a timeout, the pure, unchecked statement
is likely to fail if the window's content has changed in the meantime for
some reason. For the second variant, a part of the lookup path may be a
non-reference anyway, already causing a script error on assignment.
Therefore one should use

function submitForm(sFormName)
{
var f, t;
if (document
&& document.forms
&& (f = document.forms[sFormName])
&& ((t = typeof f.submit) == "function"
|| t == "object")
{
f.submit();
}
}

var timer = setTimeout("submitForm(" + theForm.name + ")", 2000);
PointedEars

Jul 23 '05 #4

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

var timer =
setTimeout(document.forms[theForm.name].submit, 2000);

Does this work consistently? I can imagine implementations where
the submit function is the same for all forms, and relies on the
"this" reference to find out which form to submit. That would break
here because the function is called with the global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000);
to be safe, but I don't know if there is a browser where the former
version would break.

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

Jul 23 '05 #5

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
var timer =
setTimeout(document.forms[theForm.name].submit, 2000);

Does this work consistently? I can imagine implementations where
the submit function is the same for all forms, and relies on the
"this" reference to find out which form to submit. That would break
here because the function is called with the global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000);
to be safe, but I don't know if there is a browser where the former
version would break.

Sorry, I don't see why `this' in a submit() method called from
a global wrapper function is any different from the direct call.
PointedEars

Jul 23 '05 #6

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
var timer = setTimeout(document.forms[theForm.name].submit, 2000);
Does this work consistently?

I'm pretty sure it does.
I can imagine implementations where the submit function is the same for
all forms, and relies on the "this" reference to find out which form to
submit. That would break here because the function is called with the
global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000); to
be safe, but I don't know if there is a browser where the former version
would break.

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.
PointedEars

Jul 23 '05 #7

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn wrote:

Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
var timer = setTimeout(document.forms[theForm.name].submit, 2000);

Does this work consistently?
I can imagine implementations where the submit function is the same for
all forms, and relies on the "this" reference to find out which form to
submit. That would break here because the function is called with the
global object as "this".

I would write
setTimeout(function(){document.forms[theForm.name].submit();},2000); to
be safe, but I don't know if there is a browser where the former version
would break.

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.

To clarify this: AIUI the above is semantically equivalent to

// The real constructor would be an internal implementation
// of W3C DOM's HTMLFormElement interface
function HTMLFormElement()
{
}

// By making submit() a prototype method (as it actually is),
// I have a "submit function [that] is the same for all forms
// and relies on the 'this' reference to find out which form
// to submit." as Lasse described.
HTMLFormElement.prototype.submit = function submit()
{
// The form is submitted here. I also return
// the `this' reference for test purposes.
return this;
}

// When the document is parsed, "form" elements
// are created as HTMLFormElement DOM objects
document.forms[theForm.name] = new HTMLFormElement;

// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;

// I use the reference as argument for setTimeout
var timer = setTimeout(theFormSubmit, 2000);

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object. The `this' reference
nevertheless refers to the respective HTMLFormElement object, no matter
if theFormSubmit() is called like the above (my solution) or in a wrapper
function (as Lasse's solution):

// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}

// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true

AFAIS the only thing that differs here is the stack (trace).
Am I missing something?
PointedEars

Jul 23 '05 #8

Michael Winter

On Thu, 22 Apr 2004 18:00:06 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

[snip]

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.

It's a big one, as this snippet should show:

var obj = new ( function() {
var base = this;

this.method = function() {
alert( this == base );
};
});
var method = obj.method;

obj.method();
method();

In the first call, using a qualified reference, the this operator
correctly refers to the object, obj. In the second, unqualified call, the
this operator is not set as desired. It will, in fact, refer to the global
object. You would need to use call() to correctly apply the second
approach.

I learnt this in a similar way, using setTimeout() to directly call a
method.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

Jul 23 '05 #9

Thomas 'PointedEars' Lahn

Michael Winter wrote:

On Thu, 22 Apr 2004 18:00:06 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Please shorten your attribution.
[snip]
Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.

It's a big one, as this snippet should show:

var obj = new ( function() {
var base = this;

this.method = function() {
alert( this == base );
};
});
var method = obj.method;

obj.method();
method();

I already know that. The discussion you snipped was about using a
wrapper function or not. Taking your example, my tests show that it
makes no difference to `this' if obj.method() is called directly or
via

function foo()
{
obj.method();
}

foo();

since the calling object is always `obj'.

BTW: Your From address violates Internet/NetNews standards.
PointedEars

Jul 23 '05 #10

Richard Cornford

Thomas 'PointedEars' Lahn wrote:

Thomas 'PointedEars' Lahn wrote:

<snip>

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method
called directly in the global execution context.

To clarify this: AIUI the above is semantically equivalent to

// The real constructor would be an internal implementation
// of W3C DOM's HTMLFormElement interface
function HTMLFormElement()
{
}

// By making submit() a prototype method (as it actually is),
// I have a "submit function [that] is the same for all forms
// and relies on the 'this' reference to find out which form
// to submit." as Lasse described.
HTMLFormElement.prototype.submit = function submit()
{
// The form is submitted here. I also return
// the `this' reference for test purposes.
return this;
}

// When the document is parsed, "form" elements
// are created as HTMLFormElement DOM objects
document.forms[theForm.name] = new HTMLFormElement;

// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;

// I use the reference as argument for setTimeout
var timer = setTimeout(theFormSubmit, 2000);

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object. The `this' reference
nevertheless refers to the respective HTMLFormElement object, no
matter if theFormSubmit() is called like the above (my solution) or
in a wrapper function (as Lasse's solution):

// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}

// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true

AFAIS the only thing that differs here is the stack (trace).
Am I missing something?

Yes, your test is being skewed by assigning a reference to the function
object, that has been assigned to the prototype of HTMLFormElement, to a
global variable. The effect is that the function is called in the same
way in each context.

In Lasse's example the wrapper function took the form:-

function(){
document.forms[theForm.name].submit();
}

- Making it a - CallExpression -> MemberExpression Arguments - (with an
empty arguments list). MemberExpression evaluates to an internal
Reference type with - document.forms[theForm.name] - as its base object
and "submit" as its property name, when executed -
document.forms[theForm.name] - becomes the - this - object.

But in:-

function(){
return theFormSubmit();
}

The identifier - theFormSubmit - evaluates as a Reference type with the
global object as the base object and the property name "theFormSubmit".
So the - this - object for the execution of the function is the global
object (at least that is what the specs say should happen).

Unsurprisingly:-

| alert(theFormSubmit() == lrnSubmitWrapper()); // true
| alert(theFormSubmit() === lrnSubmitWrapper()); // true

- alerts true as the function is being executed with the - this -
reference set to the global object in both cases.

Personally I would expect the original:-

| setTimeout(document.forms[theForm.name].submit, 2000);

- to be problematic for exactly the reasons that Lasse did. Although the
MemberExpression - document.forms[theForm.name].submit - in the
arguments list for setTimeout will evaluate as a Reference type that
has - document.forms[theForm.name] - as its base object and the property
name "submit", the evaluation of the arguments list will call the
internal GetValue function, passing that Reference as an argument and
returning a value that is a function object. Any association with the -
document.forms[theForm.name] - object is lost at this point.

In principle, when setTimeout calls that function object it will be as a
property of the Activation object belonging to its execution context.
And step 7 in the Function Calls algorithm (section 11.2.3) requires
function properties of an Activation object to be called with a null -
this - value (which means the global object will be used in the pace of
null during the function call).

Richard.

Jul 23 '05 #11

Yann-Erwan Perio

Thomas 'PointedEars' Lahn wrote:

Sorry, I fail to see the difference between the `this' reference in a
submit() method called from a global wrapper function in the global
execution context, and the `this' reference in a submit() method called
directly in the global execution context.

Some browsers, like Mozilla, implement host objects in a prototype-like
fashion; in this case, it is not unrealistic to consider there's a sort
of "this" value which is internally handled, and that the determination
of this "this" value follows the same rules as in javascript. Hence
Lasse's answer, which is exactly what should be done IMHO.
// Retrieve a reference to the submit() method of that new object
// as the script engine does internally (see ECMAScript 3)
var theFormSubmit = document.forms[theForm.name].submit;
That's incorrect, you'd be getting the submit *function*, but the "this"
value would be the global object(see ECMAScript 3:-)) - if the function
knows the "this" value, then that's an IE-like behavior, not a
javascript one.

var x="48";
var foo={bar:function(){alert(this.x)}, x:"42"};
var foobar=foo.bar;
foo.bar(); //42
foobar(); //48

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object.
That's probably true, still you simplify too much; as an argument of the
setTimeout function, the way theFormSubmit is called (that is, how its
scope chain is defined) depends on setTimeout implementation, not of
setTimeout "base object".

Still, what would you expect from:

var foo=1;
setTimeout("alert(this.foo)", 1);
setTimeout.apply({foo:2}, ["alert(this.foo)", 1]);
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();

Nope, Lasse has fully qualified the submit method... Did you try your
example in Mozilla, or only IE;-)
HTH
Yep.

Jul 23 '05 #12

Michael Winter

On Thu, 22 Apr 2004 19:51:14 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Michael Winter wrote:
On Thu, 22 Apr 2004 18:00:06 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Please shorten your attribution.

You know I'm not going to, so there isn't much point in asking. :P

[snip]
I already know that.
Probably, but if so, you're missing the point.
The discussion you snipped was about using a wrapper function or not.
I knew precisely what your discussion was about, and my post addressed it.
Taking your example, my tests show that it makes no difference to
`this' if obj.method() is called directly or via

function foo()
{
obj.method();
}

foo();

since the calling object is always `obj'.
I know, but that isn't the case when you omit the calling object, which is
effectively what happens when you pass setTimeout() a function reference.
This leads to it being called unqualified (that is, with "this" set to the
global object), which might lead to an error. Wrapping a qualified
reference in a globally defined function (or an anonymous one in this
case), avoids that. Replace

method();

with

setTimeout( obj.method, 1000 );

and you'll see that they're equivalent. Then perform

setTimeout( function() { obj.method(); }, 1000 );

and you'll see that it and

obj.method();

are equivalent.
BTW: Your From address violates Internet/NetNews standards.

I know. You've already told me. However, people still e-mail me, so it
can't that big a deal.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

Jul 23 '05 #13

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

// The wrapper function that Lasse defined as anonymous;
// I use a named function to show the reference.
function lrnSubmitWrapper()
{
// I return the retrieved `this' reference for test purposes
return theFormSubmit();
}
That was not what I wrote. Rather, I called the function as a method
of an object.
// I use the reference to the wrapper function as argument;
// again: that's what the script engine does internally.
var timer = setTimeout(lrnSubmitWrapper, 2000);

That's quite easy to test:

alert(theFormSubmit() == lrnSubmitWrapper()); // true
alert(theFormSubmit() === lrnSubmitWrapper()); // true
Yes, but also:
alert(theFormSubmit() == window); // true
AFAIS the only thing that differs here is the stack (trace).
Am I missing something?

Yes, when a function is being called as a method and when it is being
called as a pure function.

Take this as a simple example:

<script type="text/javascript">
var foo = 42; // global variable
var obj = { foo : 37,
method : function() { alert(this.foo); } };

setTimeout(obj.method,1000);
setTimeout(function(){obj.method();},2000);
</script>

If the two approaches are equivalent, then the alerts should be the same.
They are not. The first is 42, showing that the method has lost its
association to "obj", while the second is 37.

The same can happen for form submits. Passing the form submit function
alone can leave a function that doesn't know which form to submit, while
passing the wrapped method call will always work.

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

Jul 23 '05 #14

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

<script type="text/javascript">
var foo = 42; // global variable
var obj = { foo : 37,
method : function() { alert(this.foo); } };

setTimeout(obj.method,1000);
setTimeout(function(){obj.method();},2000);
</script>

If the two approaches are equivalent, then the alerts should be the same.
They are not. The first is 42, showing that the method has lost its
association to "obj", while the second is 37.
I see. The first one is merely a reference to some Function
object from the view of the calling global/window object!
Thank you very much for your explanation.
The same can happen for form submits. Passing the form submit function
alone can leave a function that doesn't know which form to submit, while
passing the wrapped method call will always work.

ACK, though I would prefer

setTimeout(function foo() { obj.method(); }, 2000);

for backwards compatibility.
PointedEars

Jul 23 '05 #15

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

ACK, though I would prefer

setTimeout(function foo() { obj.method(); }, 2000);

for backwards compatibility.

Depending on how much you care about backwarts compatability,
you might have to do:
setTimeout("global.path.to.obj.method()",2000);

I don't like writing code inside strings, for many of the same reasons
that I don't like using "eval", but IE 4 and NS 3 needs it.

Which browsers will not understand anonymous functions, but do
understand functional arguments to setTimeout? I don't know of any
on the Windows platform.

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

Jul 23 '05 #16

Dr John Stockton

JRS: In article <40**************@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<Po*********@web.de> posted at Thu, 22 Apr 2004 19:51:14 :

BTW: Your From address violates Internet/NetNews standards.

I doubt it. Please quote the standard to which you refer.

By the way, Hunnish attitudes went quite out of fashion after 1914-1918.

If Thomas Lahn is your real name, and if a potential employer should
search the Net for it, then ISTM that he/she will discover the
unattractiveness of your personality.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

Jul 23 '05 #17

Jim Ley

On Wed, 21 Apr 2004 05:28:06 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

the IE-DOM does support
function references from v5.0 on, but not additional arguments to date
(IE 6.0 SP-1) --

There's no way it can since that would break compatibility with every
previous version of _IE_ remember IE's DOM methods are not tied to a
particular script language, and the 3rd parameter of setTimeout is the
language.

setTimeout is a lousy way to cause a delay in a DOM anyway.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #18

Jim Ley

On Thu, 22 Apr 2004 19:26:06 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

setTimeout() is a method of the global object, so the object calling
theFormSubmit() is always the global object.

no setTimeout is a method of the window object, it may not be the same
as the global object

win=window.open('','a');
win.setTimeout("alert(this.name)",100)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #19

Jim Ley

On Fri, 23 Apr 2004 19:06:54 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com> wrote:

Which browsers will not understand anonymous functions, but do
understand functional arguments to setTimeout? I don't know of any
on the Windows platform.

ASV3 with its internal script engine will IIRC.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #20

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

Which browsers will not understand anonymous functions, but do
understand functional arguments to setTimeout? I don't know of any
on the Windows platform.

As for JavaScript, the definition of anonymous functions _using the
"function" operator_ is described to be possible since JavaScript 1.5.

<devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/ops.html#1066344>

It nevertheless works in Netscape 4.8 that is described to support
JavaScript 1.3 or 1.4 only.

Passing a Function object reference to setTimeout() is possible in
JavaScript 1.2 and 1.3 (the window object is removed from the core
language in v1.4):

<devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/window.html#1203758>
But the Gecko DOM Reference is misleading:

<http://www.mozilla.org/docs/dom/domref/dom_window_ref115.html#1021427>

Gecko in fact supports both strings and Function object references as first
argument for setTimeout().
As for JScript, the "function" operator is _not specified_ (it is not even
specified that the function identifier may be omitted in the "function"
statement specification, if we assume that what is specified as operator
in ECMAScript 3 is considered a statement in JScript:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jslrfjscriptstatementstoc.asp>

) but working as supposed in IE 5.01 SP2 (NT version) with JScript 5.1.5010
and IE 6.0 SP2 (Win2k) with JScript 5.6.8513. I would be glad if someone
who has IE < 5 installed would test this.

The MS implementation of setTimeout() takes a Function object reference
(described as "function pointer") from IE version 5 on:

<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/dhtml_node_entry.asp>

Tested successfully with both of the above UAs/script engines.
Opera 6.05+ supports both features.
HTH

PointedEars

Jul 23 '05 #21

Thomas 'PointedEars' Lahn

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:
the IE-DOM does support function references from v5.0 on, but not
additional arguments to date (IE 6.0 SP-1) --
There's no way it can since that would break compatibility with every
previous version of _IE_

Why? Scripts for previous versions would not use the third argument.
remember IE's DOM methods are not tied to a particular script language,
and the 3rd parameter of setTimeout is the language.
If the script engine does not support the additional feature that's OK, but
there are other examples (take try...catch..finally or non-greedy RegExp
quantifiers) where this was done.
setTimeout is a lousy way to cause a delay in a DOM anyway.

Are you proposing a sleep() method instead, blocking the UA when called?
PointedEars

Jul 23 '05 #22

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Are you proposing a sleep() method instead, blocking the UA when called?

That would probably be what most people really want.
It doesn't have to block the UA, just the current execution context.
It should then resume executing after the time us up, or at least
as soon as no other scheduled execution is running. It could work.

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

Jul 23 '05 #23

optimistx

Dr John Stockton wrote:

JRS: In article <40**************@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<Po*********@web.de> posted at Thu, 22 Apr 2004 19:51:14 :

BTW: Your From address violates Internet/NetNews standards.

I doubt it. Please quote the standard to which you refer.

By the way, Hunnish attitudes went quite out of fashion after 1914-1918.

If Thomas Lahn is your real name, and if a potential employer should
search the Net for it, then ISTM that he/she will discover the
unattractiveness of your personality.

It is easier to tolerate and understand astonishing features, if one
puts e.g. an expression 'asperger syndrome' to google.com and reads some
key articles.

It helps me tolerate by imagining that my sick child would try to
continue his/her living here with the resources he/she has.

Jul 23 '05 #24

Thomas 'PointedEars' Lahn

optimistx wrote:

Dr John Stockton wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> posted:
BTW: Your From address violates Internet/NetNews standards.

I doubt it. Please quote the standard to which you refer.

| From: Michael Winter <M.******@blueyonder.co.invalid>
^^^^^^^^

[2004-04-24 17:47:26] pointedears:/var
$ chkmadd -v M.******@blueyonder.co.invalid
chkmadd 0.1.2.2004042206 -- (C) 2003, 2004 Thomas Lahn <me**@PointedEars.de>
Distributed under the terms of the GNU General Public License (GPL).
See COPYING file or <http://www.fsf.org/copyleft/gpl.html> for details.
Report bugs to <ch*****@PointedEars.de>.

E-mail address(es) to check:
M.******@blueyonder.co.invalid

Verifying <M.******@blueyonder.co.invalid> ...
Mail exchanger(s) for blueyonder.co.invalid:
None.
Mail exchanger(s) for co.invalid:
None, thus <M.******@blueyonder.co.invalid>
is definitely not an e-mail address (no MX).

---------------------
Network Working Group D. Eastlake
Request for Comments: 2606 A. Panitz
BCP: 32 June 1999
Category: Best Current Practice

Reserved Top Level DNS Names

[...]

Abstract

To reduce the likelihood of conflict and confusion, a few top level
^^^^^^^^^^^^^^^
domain names are reserved for use in private testing, as examples in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
documentation, and the like. In addition, a few second level domain
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
names reserved for use as examples are documented.

[...]

2. TLDs for Testing, & Documentation Examples
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
^^^^^^^^^^^^^^^^^^^^^^^
testing of existing DNS related code, examples in documentation, DNS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
related experimentation, invalid DNS names, or other similar uses.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^

For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.

To safely satisfy these needs, four domain names are reserved as
listed and described below.

.test
.example
.invalid
.localhost

[...]

".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.

[...]

---------------------
Network Working Group P. Resnick, Editor
Request for Comments: 2822 QUALCOMM Incorporated
Obsoletes: 822 April 2001
Category: Standards Track

Internet Message Format

[...]

3.6.2. Originator fields

The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.

from = "From:" mailbox-list CRLF

[...]
3.4. Address Specification

Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes.

[...]

mailbox = name-addr / addr-spec

name-addr = [display-name] angle-addr

name-addr = [display-name] angle-addr

angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr

[...]

A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^
---------------------

A good informal explanation why such address munging is a Bad Thing[1]:

<http://www.interhack.net/pubs/munging-harmful/>
HTH & HAND

PointedEars
___________
[1] http://catb.org/~esr/jargon/html/B/Bad-Thing.html

Jul 23 '05 #25

Dr John Stockton

JRS: In article <40************@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<Po*********@web.de> posted at Sat, 24 Apr 2004 18:55:06 :

optimistx wrote:
Dr John Stockton wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> posted:
BTW: Your From address violates Internet/NetNews standards.

I doubt it. Please quote the standard to which you refer.

Network Working Group D. Eastlake
Request for Comments: 2606 A. Panitz
BCP: 32 June 1999
Category: Best Current Practice To reduce the likelihood of conflict and confusion, a few top level
^^^^^^^^^^^^^^^
domain names are reserved for use in private testing, as examples in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
documentation, and the like.

Note - "and the like".

".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.

The TLD having been declared unusable for cross-net communication, it is
entirely reasonable to use it for non-communication.

Circumstances have changed since the time when it was not felt necessary
for that document to deal with anti-spam precautions, so nothing can be
read into the omission in respect to present-day usage.

Grow up. Remember what happened to Benito - according to Niven &
Pournelle, he eventually reaped the reward of honourable behaviour.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Jul 23 '05 #26

Jim Ley

On Fri, 23 Apr 2004 22:46:48 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
the IE-DOM does support function references from v5.0 on, but not
additional arguments to date (IE 6.0 SP-1) --

There's no way it can since that would break compatibility with every
previous version of _IE_

Why? Scripts for previous versions would not use the third argument.

yet, it's near impossible to do version detection of javascript...

setTimeout is a lousy way to cause a delay in a DOM anyway.

Are you proposing a sleep() method instead, blocking the UA when called?

Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. Although even the current SVG 1.2
proposal I welcome as better than setTimeout, which really is lousy.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #27

Yann-Erwan Perio

Jim Ley wrote:

yet, it's near impossible to do version detection of javascript...
Ah, but I assume that detecting JScript wouldn't be too hard, using
conditional compilation and VBArrays...or not?
Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. Although even the current SVG 1.2
proposal I welcome as better than setTimeout, which really is lousy.

When reading your first answer I was about to exemplify good uses for
setTimeout (other than addressing browser lack of support for events),
but the more I think to that delayed dispatchEvent, the more valid it
seems to be.

I'm not familiar with SVG yet, scanning the SVG1.2 draft yielded the
SVGRunnable and SVGTimer interfaces, do you really prefer this over
setTimeout?

I mean, it's possible to implement elegant components using setTimeout,
and to me the spec is just proposing an interface to such a component,
which, though IMHO quite correct, remains easily done with javascript
and setTimeout, and seems moreover to be missing the spirit of an
events-based system.

At least setTimeout is much more fun:-), and it being easy to use means
more flexibility for the programmer - I don't see any real added value
or innovation in the SVG two interfaces.

As for the "sleep" method, I hate the idea - that'd split the execution
context, so that would deal with javascript, while the timeout only
deals with the host, much neater.
Cheers,
Yep.

Jul 23 '05 #28

Thomas 'PointedEars' Lahn

Jim Ley wrote:

Thomas 'PointedEars' Lahn wrote:
Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
the IE-DOM does support function references from v5.0 on, but not
additional arguments to date (IE 6.0 SP-1) --

There's no way it can since that would break compatibility with every
previous version of _IE_

Why? Scripts for previous versions would not use the third argument.

yet, it's near impossible to do version detection of javascript...

Since JavaScript methods do not have fixed arity I still do not see the
problem. No edition/version of ECMAScript, JavaScript and JScript is 100%
backwards compatible.

setTimeout is a lousy way to cause a delay in a DOM anyway.

Are you proposing a sleep() method instead, blocking the UA when called?

Nope, my proposal (which you can see in the www-svg archives) would be
for a delayed dispatchEvent. [...]

ACK, a standards compliant way of setting a timeout is required.
PointedEars

Jul 23 '05 #29

Jim Ley

On Mon, 26 Apr 2004 22:24:47 +0200, Yann-Erwan Perio
<y-*******@em-lyon.com> wrote:

I'm not familiar with SVG yet, scanning the SVG1.2 draft yielded the
SVGRunnable and SVGTimer interfaces, do you really prefer this over
setTimeout?
Possibly not over the setTimeout which takes function reference as
first parameter, and other optional parameters, however due to the
built in weight of setTimeout if it was standardised, everyone would
expect setTimeout("chicken()",100) to work, and I think that's
horrible.

I mean, it's possible to implement elegant components using setTimeout,
and to me the spec is just proposing an interface to such a component,
which, though IMHO quite correct, remains easily done with javascript
and setTimeout, and seems moreover to be missing the spirit of an
events-based system.

Yep, Jan-Klaas Kollhof has implemented it using setTimeout, the
problem with setTimeout is that with the compilation you can't do it
in the compact profile of ECMAScript or in most other langauges, and
DOM is supposed to be language neutral.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #30

setTimeout not executing form submit

Similar topics