IE6 Nesting Problem?

[bweaverusenet]

Hi. I am trying to get some javascript to work in IE6, from the
address line. It works in Firefox and, I believe, IE7.

It appears that with some number of nested structures, the code does
not execute. Take a level or two out and it works. The code below is
nonsense, but illustrates the problem.

This works:

javascript: for( a=1;a<=10;a++ ) { for( b=1;b<=10;b++ ) { if( q<1000 )
{ for( c=1;c<=10;c++ ) { for( d=1;d<=10;d++ ) { if( a 0 ) { if( a <
2000 ) { x=10; q++; } } } } } } } for( a=1;a<=10;a++ )
{ for( b=1;b<=10;b++ ) { if( q<1000 ) { for( c=1;c<=10;c++ )
{ for( d=1;d<=10;d++ ) { if( a 0 ) { x=10; q++; } } } } } }
alert( q ); void( 0 );

But this doesn't:

javascript: for( a=1;a<=10;a++ ) { for( b=1;b<=10;b++ ) { if( q<1000 )
{ for( c=1;c<=10;c++ ) { for( d=1;d<=10;d++ ) { if( a 0 ) { if( a <
2000 ) { x=10; q++; } } } } } } } for( a=1;a<=10;a++ )
{ for( b=1;b<=10;b++ ) { if( q<1000 ) { for( c=1;c<=10;c++ )
{ for( d=1;d<=10;d++ ) { if( a 0 ) { if( a < 2000 ) { x=10; q+
+; } } } } } } } alert( q ); void( 0 );

I've tried declaring the variables, blah blah blah. Still breaks. Is
this a memory issue? Am I missing something obvious in the code?
Thanks for any help!

Here's a prettied version:

javascript:
for( a=1;a<=10;a++ ) {
for( b=1;b<=10;b++ ) {
if( q<1000 ) {
for( c=1;c<=10;c++ ) {
for( d=1;d<=10;d++ ) {
if( a 0 ) {
if( a < 2000 ) {
x=10;
q++;
}
}
}
}
}
}
}
for( a=1;a<=10;a++ ) {
for( b=1;b<=10;b++ ) {
if( q<1000 ) {
for( c=1;c<=10;c++ ) {
for( d=1;d<=10;d++ ) {
if( a 0 ) {
if( a < 2000 ) {
x=10;
q++;
}
}
}
}
}
}
}
alert( q );
void( 0 );

[Richard Cornford]

"VK" <sc**********@y ahoo.comwrote:

On Mar 17, 3:14 pm, Richard Cornford wrote:

>In order to explain anything it would be necessary to
understand it, and VK ...

<snip the rest of the standard preface>

<snip a very detailed but irrelevant explanation of how
javascript treats different values in boolean checks>

>However, in the event that this code was exposed to an
environment where the browser had not provided a 'window'
property

<snip>

>the attempt to type-convert the result of resolving - window -

<snip>

>would result in a runtime error.

Right. So if (window) check is superfluous and useless here.
My mistake.

* full void wrap - you mean instead of the final void(0), right?

VK has a strong, and apparently unshakable, belief in the magical
powers of the javascript - void - operator.

While Mr.Cornford has a strong, and apparently unshakable, belief in
the harmful nature of void.

Do I? What evidence do you base that upon? All I have said here is that
an operator that evaluates its operant and then results in the undefined
value is pointless when its operand is already guaranteed to evaluate to
the undefined value. Pointing out that something is pointless in the
context in which it is used is hardly suggesting that it is harmful.
There is potentially harm in your suggesting to people who don't know any
better that there may be some purpose in wrapping - void( ... ) - around
everything in sight.

For him worser than void expression can be
only void(expression )
We'll stop right here.

>An expression representing a call to any function (technically, a
CallExpression ) evaluates as the value returned from the function
call.
If the body of a function is exited via a return statement and that
return statement specifies a value to be returned then it is that
value
that becomes the value of the entire CallExpression.

You missed the whole idea of (function(){})( ) usage here -
as well as the shy namespace concept.

Did I?

I don't care of the return value.

Yes, you have never really understood the behaviour of functions in
javascript, hence your inability to grasp when the code you are writing
includes things that are no more than mystical incantations.

Think of HTML page with its own script. If on this page one
chooses a bookmarklet of a kind javascript:var foo='bar';
then where variable foo goes?

As that expression evaluates to a non-empty string the bookmarklet will
result in the current page being replaced so wherever the variable ends
up doesn't matter at all as it is immediately destroyed wherever it ends
up.

But what has that to do with pointlessly wrapping a call to an anonymous
function expression that has no return statement in a void operation?

Richard.

[bweaverusenet]

On Mar 18, 8:49 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

<bweaveruse...@ gmail.comwrote:

but can you explain the void( ... ) comments maybe a little
more succinctly? Best I can understand so far is that
(function(){ ... }()) is superior to void(function() { ... }()).

The first is not superior, in itself, it is just sufficient for the task.
When the anonymous function contains no return statement at all (or when
it contains a return statement that does not specify any other value) the
value of the expression - (function(){ .... })() - is the undefined
value. The value of the expression - void(function() { ... }()) - is the
undefined value. It is in fact the point of the void operator that it
evaluates its operand and then results in the undefined value. However,
if you can guarantee that the expression that is the operand of void will
evaluate to the undefined value (as you can when the expression is a call
to an anonymous function expression where the function contains no return
statement) it is pointless to make it the subject of a void operation.

If I've diagrammed your sentences correctly :-) I think I get it now.

It is not a characteristic of programmers that they write code that
performs operations that they know to be pointless at the point of
writing them. Doing so would be irrational.

However, it *is* a characteristic of programmers to cut and paste or
try to cobble things together from various sources until they fully
understand an issue. They sometimes post questions to USENET to learn
more. :-)

RobG, I think you missed my original point about the 'q'
error, that I understand that it should be defined, but it
was not relevant to the bookmarketlet size limit behavior
that I was seeing.

Maybe not, but the error that followed form the undeclared - q - is the
same error that must follow from the undeclared - window - in
environments that do not provide a - window - property of the global
object natively.

Uh, okay. Still not sure the relevance of this.

VK is very good at providing examples of things that should not be done.
It is just a pity he does it so relentlessly.

No, on the contrary, it is great. (At least in this case.) He got the
conversation going about void(), if(window), and anonymous function
wrappers. From there I've learned that learned about ( ... ) vs.
void( ... ), that if( window ) is pointless, and learned a little more
about function() { ... } ().

If you are not willing to put the call to your - hi - function at the end
of your - hi.js - file (which is probably the best way of guaranteeing
that the function is defined prior to the first call to it) then you

I appreciate and understand the suggestion, and intend to use it
elsewhere. But as I pointed out in a prior post, the .js file in this
situation contains several functions that might be called, of which
hi() is only one.

could avoid the try-catch with a typeof test (typeof dos not error if its
subject is undeclared):-

javascript:
(function() {
function f(){
if(typeof hi == 'function'){
hi();
}else{
setTiemout(f,10 );
}
}
var js=document.cre ateElement("SCR IPT");
js.src="http://localhost/hi.js";
document.getEle mentsByTagName( "HEAD")[0].appendChild(js );
f();
}());

I like this a lot and will use it instead. Relying on try-catch felt
wrong and I'm glad to have a way to avoid it.

I just wish there was an event-driven solution. I.e. I wish I could
call hi() once a loading-complete event fired (yes, yes, inline in
the .js file, but that's a not going to work in this case).

Though 10 milliseconds is a very short interval for a setTiemout.
Remembers that humans tend to take about 400 milliseconds to react to
anything, so a timeout of 100 milliseconds would be plenty fast enough.

Point taken.

Thanks! Learning a lot here.

[Richard Cornford]

<bw***********@ gmail.comwrote:

On Mar 18, 8:49 pm, Richard Cornford wrote:

><bweaveruse... @gmail.comwrote :

<snip>

>It is not a characteristic of programmers that they write code that
performs operations that they know to be pointless at the point of
writing them. Doing so would be irrational.

However, it *is* a characteristic of programmers to cut and paste or
try to cobble things together from various sources until they fully
understand an issue.

No, that is not programming. You are not programming until you are in
control of what you are doing.

They sometimes post questions to USENET to learn
more. :-)

That depends on who answers. If nobody had bothered to point out his
follies might you not have gone away with the impression that VK's
proposals where worthwhile an justified? And maybe thought that you had
learnt something from them? If so you would have gone away knowing less
than you had to start with because knowing that you don't know something
is knowing more than believing that you know something that is not true.

<snip>

>VK is very good at providing examples of things that should not be
done.
It is just a pity he does it so relentlessly.

No, on the contrary, it is great. (At least in this case.) He got the
conversation going about void(), if(window), and anonymous function
wrappers. From there I've learned that learned about ( ... ) vs.
void( ... ), that if( window ) is pointless, and learned a little more
about function() { ... } ().

<snip>

Think about that. You have learnt why you should not do two things that
nobody should ever have suggested you do in the first place, and two
things that you would not have added on your own account.

Richard.

[VK]

but can you explain the void( ... ) comments maybe a little

more succinctly? Best I can understand so far is that
(function(){ ... }()) is superior to void(function() { ... }()).

The first is not superior, in itself, it is just sufficient for the task.
When the anonymous function contains no return statement at all (or when
it contains a return statement that does not specify any other value) the
value of the expression - (function(){ .... })() - is the undefined
value. The value of the expression - void(function() { ... }()) - is the
undefined value. It is in fact the point of the void operator that it
evaluates its operand and then results in the undefined value. However,
if you can guarantee that the expression that is the operand of void will
evaluate to the undefined value (as you can when the expression is a call
to an anonymous function expression where the function contains no return
statement) it is pointless to make it the subject of a void operation.

If I've diagrammed your sentences correctly :-) I think I get it now.

Richard Cornford is an expert in the "set up a straw man" tactique: so
you never can be sure with him did he really misunderstood something
or is he just pulling out more argumentation out of you waiting for
some error to jump to :-) Let's take it as he really missed both
javascript:void (expression) and (function(){})( ) usage.

1) javascript:void (expression) in bookmarklet
javascript: pseudo-protocol was made to replace the current page by
content generated by the return value of the invoked javascript code.
If the invoked javascript code returns nothing then UA stays on the
same page. But in any case invoking javascript: bookmarklet puts the
browser into navigation mode until it gets informed that will be no
navigation. So by the procedure it is very close to click a link with
"204 No Content" server response behind.
I like to let the system know in advance and right away that no matter
what happens where will be no effective navigation by this link. This
is why I'm using javascript:void (the rest)

2) Shy namespace
Bookmarklet code runs in the same global space as the current page.
This way if the page already has its own script with say
var AJAX = new AjaxRequest();
and your bookmarklet has
javascript:var AJAX=new AjaxRequest()
then after executing your bookmarklet the existing script on the page
will be FUBAR. Moreover any var in your bookmarlet will be created as
global var so stay polluting the global scope. By using anonymous
function call you keep your bookmarlet "shy" and not messing with the
existing context. This is why I'm using javascript:void ((function()
{the rest})())

if(window) check is already signed off as a Cargo Cult programming
element. The main fun of it is that I was for years an opponent of
window, document, getElementById and other parasite checks. Another
proof of how does the environment affect us in oftenly hidden ways.

[Richard Cornford]

"VK" <sc**********@y ahoo.comwrote:

>>>but can you explain the void( ... ) comments maybe a little
more succinctly? Best I can understand so far is that
(function( ){ ... }()) is superior to void(function() { ... }()).

>>The first is not superior, in itself, it is just sufficient for
the task. When the anonymous function contains no return statement
at all (or when it contains a return statement that does not
specify any other value) the value of the expression - (function(){ .... })() - is the undefined
value. The value of
the expression - void(function() { ... }()) - is the undefined
value. It is in fact the point of the void operator that it
evaluates its operand and then results in the undefined value. However, if you can guarantee that
the expression that is the
operand of void will evaluate to the undefined value (as you
can when the expression is a call to an anonymous function
expression where the function contains no return
statement) it is pointless to make it the subject of a void operation.

If I've diagrammed your sentences correctly :-) I think I get it now.

Richard Cornford is an expert in the "set up a straw man"
tactique: so you never can be sure with him did he really
misunderstood something or is he just pulling out more
argumentation out of you waiting for some error to jump to

"Jump to"?

:-) Let's take it as he really missed both
javascript:void (expression) and (function(){})( )
usage.

That seems very unlikely. Of course it may seem that way to you because
your understanding of this subject is such a tangles mass of
misconceptions that you cannot actually implement the simplest javascript
function effectively.

1) javascript:void (expression) in bookmarklet
javascript: pseudo-protocol was made to replace the current page by
content generated by the return value of the invoked javascript code.

Return values are things that belong to functions. Javascript pseudo
protocol URLs are not executed as functions.

If the invoked javascript code returns nothing

In the examples under discussion the evoked javascript code is an
Expression and Expressions do not return values they evaluate to values,
and they can never evaluate to "nothing".

then UA stays on the same page.

The UA always stays on the same page, it is just that the contents of
that page may be replaced with the value of the expression if the browser
sees that value a suited to the action. The undefined value is never seen
as suited as a source to replace the page. Other values that have
falseness generally are not considered suited either, but browsers differ
in what they may employ.

But in any case invoking javascript: bookmarklet puts the
browser into navigation mode

Activating javascript pseudo protocol URLs certainly does that in at
least some browsers (most notably IE).

until it gets informed that will be no navigation.

In the case of IE <= 6 at least nothing will get the page out of its
altered state except the contents of the page being replaced by the
javascript pseudo protocol bookmark evaluating to a value that will
replace its contents.

So by the procedure it is very close to click a link with
"204 No Content" server response behind.

What is like a 204 response? Having the Expression evaluate as the
undefined value certainly does not get the page out of its altered state,
and having it evaluate as value that will replace the contents of the
page would be better compared with a 200 response.

Remember that we have repeatedly shown you that a javascript
pseudo-protocol HREF consisting of nothing but - javascript:void 0; -
will put IE <= 6 into its pending navigation state reliably:-

<URL:
http://groups.google.com/group/comp....c201699aef169e

>

<URL:
http://groups.google.com/group/comp....07ad60e4d8fe1f

>

I like to let the system know in advance and right away
that no matter what happens where will be no effective
navigation by this link.

If that is what you were doing then maybe it would be worthwhile, but
that is not what happens.

This is why I'm using javascript:void (the rest)

If that is what you were doing then maybe it would be worthwhile, but
that is not what happens.

First the browser does not get any advanced warring form the use of void
operator, the expression must still be evaluated first. It does not learn
anything any sooner. And second, the browser does not get tipped off that
navigation is not going to happen. IE <= 6 goes into its altered state
when the URL is activated and it says in that state until either the
contents of the current page are replaced or the page is replaced with
another.

And if the expression that is the operand for - void - is a call to a
function that has no return value then the expression is going to
evaluate as undefined, so using that expression as the operand for the
void operator actually delays the browser in finding out that the value
of the whole expression is going to be the undefined value.

Thus "know in advance and right away" is a total fiction, and "no matter
what happens where will be no effective navigation" is meaningless as the
browser (at least IE <= 6) still be leaves it is about to be navigated
anyway.

2) Shy namespace
Bookmarklet code runs in the same global space as the current page.
This way if the page already has its own script with say
var AJAX = new AjaxRequest();
and your bookmarklet has
javascript:var AJAX=new AjaxRequest()
then after executing your bookmarklet the existing script on
the page will be FUBAR.

Unless the point of the javascript URL is to modify the script on the
page so it behaves as the user desires.

Moreover any var in your bookmarlet will be created as
global var so stay polluting the global scope.

"Stay polluting the global scope"? What is "stay polluting"?

By using anonymous function call you keep your bookmarlet
"shy" and not messing with the existing context.

You mean that inside the anonymous function you have a private scope to
play with that will not impact upon the global scope, unless that is
wanted. We know this, indeed we spend a couple of weeks of posts
battering that fact into you just last year.

This is why I'm using javascript:void ((function()
{the rest})())

No, that is why people use - javascript:(fun ction(){ ... })(); -. The use
of the - void - operator is superfluous whenever the function does not
have a return value as the scope restrictions are a consequence of the
use of the function alone.

if(window) check is already signed off as a Cargo Cult
programming element.

Yes, you only made one post trying to present one of your fictions as an
explanation for your suggesting that mystical incantation. Hopefully some
time soon you will see the futility in wrapping calls to functions that
have no return value in void operations, and stop posting bogus attempts
to justify your mystical incarnations.

The main fun of it is that I was for years an opponent of
window, document, getElementById and other parasite checks.
Another proof of how does the environment affect us in
oftenly hidden ways.

That is more proof that a determined fool can say a fool for ever.

Richard.

[bweaverusenet]

All, I *really* appreciate the technical help with my questions. Thank
you.

However, I'm more than a little stunned at the arrogant and snarky
comments. Looking back in the archives a bit, it appears that Richard
Cornford and VK (and a couple others) have a long history of mutual
snarkiness. To be clear, I understand how these things evolve. I also
respect your intimate knowledge of Javascript. But for crying out,
please lighten up a bit.

Again, thanks for the technical answers to my questions.