Minor AJAX Problem

[Joel Byrd]

I am making an AJAX call when any one of a number of inputs in a form
(search criteria) are clicked, checked, changed, etc. When the user
clicks, checks, whatever, I am trying to display a "Retrieving
results..." text. This should be really simple, but in IE, it does not
work. Here's the code that is not executing in IE:

[-----------------------
var status_text = document.getElementById('status_text');
status_text.innerHTML = '<strong>Retrieving Users<span
id="waiting"><img src="images/waiting.gif" align="bottom"
style="margin-left: 5px;" /></span></strong>';
document.getElementById("waiting").style.display=' inline';
-------------------------]

And here is the context of that code, which is the AJAX function that
is called when a radio button is clicked, a checkbox is checked, etc.
(there's a long list of variables that I was going to leave out, but I
included everything just in case):

[-------------------------
function friendSearch() {

var status_text = document.getElementById('status_text');
status_text.innerHTML = '<strong>Retrieving Users<span
id="waiting"><img src="images/waiting.gif" align="bottom"
style="margin-left: 5px;" /></span></strong>';
document.getElementById("waiting").style.display=' inline';
//First, get all the values from the form.
var browse_what =
findChecked(document.search_users.browse_what);
var sex = findChecked(document.search_users.sex);
var age_min = document.search_users.age_min.value;
var age_max = document.search_users.age_max.value;
var marital_status =
findChecked(document.search_users.marital_status);
var are_here_for =
findChecked(document.search_users.are_here_for);
var hair_color = findChecked(document.search_users.hair_color);
var eye_color = findChecked(document.search_users.eye_color);
var body_type = findChecked(document.search_users.body_type);
var ethnicity = findChecked(document.search_users.ethnicity);
var education = findChecked(document.search_users.education);
var height = findChecked(document.search_users.height);
var height_min_feet = document.search_users.height_min_feet.value;
var height_min_inches = document.search_users.height_min_inches.value;
var height_max_feet = document.search_users.height_max_feet.value;
var height_max_inches = document.search_users.height_max_inches.value;
var rating_min = document.search_users.rating_min.value;
var rating_max = document.search_users.rating_max.value;
var smoker = findChecked(document.search_users.smoker);
var drinker = findChecked(document.search_users.drinker);
var religion = document.search_users.religion.value;
var income = document.search_users.income.value;
var children = document.search_users.children.value;
var show_only_users_with_photos =
findChecked(document.search_users.show_only_users_ with_photos);
var show_name_and_photo_only =
findChecked(document.search_users.show_name_and_ph oto_only);
var sort_by =
findChecked(document.search_users.sortby);

//Then, use ajax to commit the update.
var randomNumber = Math.floor(Math.random() * 9999999);
var page_url = 'ajax.friend_search.php?r=' + randomNumber;
page_url += '&browse_what=' + browse_what;
page_url += '&sex=' + sex;
page_url += '&age_min=' + age_min;
page_url += '&age_max=' + age_max;
page_url += '&marital_status=' + marital_status;
page_url += '&are_here_for=' + are_here_for;
page_url += '&hair_color=' + hair_color;
page_url += '&eye_color=' + eye_color;
page_url += '&body_type=' + body_type;
page_url += '&ethnicity=' + ethnicity;
page_url += '&education=' + education;
page_url += '&height=' + height;
page_url += '&height_min_feet=' + height_min_feet;
page_url += '&height_min_inches=' + height_min_inches;
page_url += '&height_max_feet=' + height_max_feet;
page_url += '&height_max_inches=' + height_max_inches;
page_url += '&rating_min=' + rating_min;
page_url += '&rating_max=' + rating_max;
page_url += '&smoker=' + smoker;
page_url += '&drinker=' + drinker;
page_url += '&religion=' + religion;
page_url += '&income=' + income;
page_url += '&children=' + children;
page_url += '&show_only_users_with_photos=' +
show_only_users_with_photos;
page_url += '&show_name_and_photo_only=' +
show_name_and_photo_only;
page_url += '&sort_by=' + sort_by;

var oAJAX = new XMLHttpRequest();

oAJAX.open("GET", page_url);
oAJAX.onreadystatechange = function() {
if (oAJAX.readyState == 4) {
if (oAJAX.status == 200) {
//Remove status text (it will be replaced by the responseText).
status_text.parentNode.removeChild(status_text);
document.getElementById('search_results').innerHTM L =
oAJAX.responseText;
} else {
//document.getElementById("errormsg").childNodes[0].nodeValue =
'There was a problem retrieving the data you requested (Error: ' +
oAJAX.statusText + '). Please try again later.';
}
}
}
oAJAX.send(null);

}//end function friendSearch
---------------------------]

So IE successfully makes the AJAX call and returns the results, but it
just does not execute that first part of the code that displays the
"Retrieving results..." text.

Any ideas?

[VK]

Joel Byrd wrote:

I am making an AJAX call when any one of a number of inputs in a form
(search criteria) are clicked, checked, changed, etc. When the user
clicks, checks, whatever, I am trying to display a "Retrieving
results..." text. This should be really simple, but in IE, it does not
work.

It shouldn't work anywhere else neither AFAIK, I guess you just checked
it under IE only ;-)

Browser graphics context is being updated only on script execution
break, until then graphics context updates are just accumulating
(despite the relevant DOM properties are already updated). More I'm
thinking of it, more I consider it to be an universal browser model
default to be fixed (by IE, Firefox and Co)
I realize the impact on the drawing engine, but really in XXI century
it is not a locking issue. Simply the performance of the drawing engine
has to be more modern.

Back to the problem:
....
document.getElementById("waiting").style.display=' inline';

Right after this line you need to give a micro-break so browser would
bring the graphics context in accordance with the updated DOM
properties.

So the rest of your ajaxoid goes to a separate function - let's call it
doAjaxRequest, and the function looks now something like:
....
document.getElementById("waiting").style.display=' inline';
setTimeout(doAjaxRequest);
// end of function
}

[Thomas 'PointedEars' Lahn]

VK wrote:

setTimeout(doAjaxRequest);

The second argument is missing (and no, there is _no_ default value
specified in any implementation), and using a Function object reference
as first argument, which is not backwards compatible, is unnecessary.

window.setTimeout("doAjaxRequest()", 50);
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:

VK wrote:

setTimeout(doAjaxRequest);

The second argument is missing (and no, there is _no_ default value
specified in any implementation), and using a Function object reference
as first argument, which is not backwards compatible, is unnecessary.

window.setTimeout("doAjaxRequest()", 50);

It is not enough for my Windows 98 SE I'using at this moment. The
smallest non-rounded tick is 58ms for me, so
setTimeout("doAjaxRequest()", 50) will lead to the extra tick and 42ms
vasted. At the same time on better systems
setTimeout("doAjaxRequest()", 60) will lead to up to 50ms vasted.

It is all little stuff really, but why vaste anything? It is better to
let the system to choose the smallest interval.

[Thomas 'PointedEars' Lahn]

VK wrote:

Thomas 'PointedEars' Lahn wrote:

VK wrote:

> setTimeout(doAjaxRequest); The second argument is missing (and no, there is _no_ default value
specified in any implementation), and using a Function object reference
as first argument, which is not backwards compatible, is unnecessary.

window.setTimeout("doAjaxRequest()", 50);

It is not enough for my Windows 98 SE I'using at this moment. The
smallest non-rounded tick is 58ms for me, so
setTimeout("doAjaxRequest()", 50) will lead to the extra tick and 42ms
vasted. At the same time on better systems
setTimeout("doAjaxRequest()", 60) will lead to up to 50ms vasted.

Noted.
It is all little stuff really,
So it does not really matter as long as it is longer or equal to the
fastest timer of target operating systems, yes?
but why vaste anything? It is better to let the system to choose the
smallest interval.

There is no default value.
PointedEars

[Joel Byrd]

>>Browser graphics context is being updated only on script execution

break, until then graphics context updates are just accumulating
(despite the relevant DOM properties are already updated).

Oh, really? I didn't know that. What exactly is a "script execution
break"? (I'm guessing it means when the normal flow of code is broken,
like in the case of a function call - would there be other examples of
a script execution break?)

[Joel Byrd]

>>It shouldn't work anywhere else neither AFAIK, I guess you just checked

it under IE only ;-)

No, in fact it works in Firefox as I had originally expected.

[VK]

Joel Byrd wrote:

Browser graphics context is being updated only on script execution
break, until then graphics context updates are just accumulating
(despite the relevant DOM properties are already updated).

Oh, really? I didn't know that.

Always something new to learn ;-)
What exactly is a "script execution
break"? (I'm guessing it means when the normal flow of code is broken,
like in the case of a function call - would there be other examples of
a script execution break?)
Sorry, wrong term from my side (used "break" in the common sense while
it has a heavy meaning tradition in the programming). I should say
"exit from the execution context" (?)
Like at the end of some function if you are not calling another
function, or by alert() or by setTimeout() / setInterval()
No, in fact it works in Firefox as I had originally expected.

As I said it's a cross-browser behavior so this cannot be true. Either
you have a "break" in your code, or Firefox is now adjusted to treat
XMLHttpRequest as a "break" to update graphics context. If the latter
is true (I did not check yet) then it's a good improvement.

Here is the code to illustrate your problem:
(run as it is first, then comment test and try test2 instead)
(watch line breaks as usual)

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

var x = -1;
var y = -1;

function coordX() {
return ++x + 'px';
}

function coordY() {
return ++y + 'px';
}

function showID() {
alert(this.$.$.id);
}

function customDIV(id) {
this.$ = document.createElement('DIV');
this.$.$ = this;
this.$.id = id || 'oid'+(new Date()).getTime();
with (this.$.style) {
width = '100px';
height = '100px';
position = 'absolute';
left = coordX();
top = coordY();
backgroundColor = '#FFFF33';
border = '1px blue solid';
}
this.$.onclick = showID;
return this.$;
}

function test() {
if (test.i < 100) {
document.body.appendChild(new customDIV());
test.i++;
setTimeout('test()');
}
} test.i = 0;
function test2() {
while(test2.i < 100) {
document.body.appendChild(new customDIV());
test2.i++;
for (var i=0; i<10000; i++) {
var j = null;
}
}
} test2.i = 0;

window.onload = test;
//window.onload = test2;
</script>
</head>

<body>

</body>
</html>

[Richard Cornford]

VK wrote:
<snip>

... I should say
"exit from the execution context" (?)
No you should not. Prior to using terminology as precise as 'execution
context' is in the context of javascript it is a good idea to
familiarise yourself with what it means. Returning form any function is
exiting an execution context.
Like at the end of some function
Which would be exiting an execution context.
if you are not calling another function,
But that qualification makes describing the action as to "exit from the
execution context" inappropriate and misleading. Just another
demonstration of a shortfall in technical understanding on your part.

<snip>

No, in fact it works in Firefox as I had originally expected.

As I said it's a cross-browser behavior so this cannot be true.

Nobody in their right mind would take your proclamations on what is, or
is not, cross-browser seriously.

<snip> function showID() {
alert(this.$.$.id);
You silly sod. You have tied yourself up in knots so much that you
cannot see that - this.$.$.id - is exactly the same as - this.id -.
} function customDIV(id) {
this.$ = document.createElement('DIV');
this.$.$ = this;

<snip>

Another example of the "worst possible" from VK. Obscure, convoluted and
one of the shortest circular references including a DOM node possible.

Richard.

[VK]

Richard Cornford wrote:

Nobody in their right mind would take your proclamations on what is, or
is not, cross-browser seriously.
No one have to believe VK. Believe to your own eyes: the code is here.
Simply compare screen redraw behavior with test and test2.
<snip>

function showID() {
alert(this.$.$.id);

You silly sod. You have tied yourself up in knots so much that you
cannot see that - this.$.$.id - is exactly the same as - this.id -.

No - read the code right. The constructor returns augmented div itself,
not a JavaScript object.

function customDIV(id) {
this.$ = document.createElement('DIV');
this.$.$ = this;

<snip>

Obscure, convoluted and one of the shortest
circular references including a DOM node possible.

That "circular reference" is a real bogeyman of JavaScript recently :-)
Every time something goes wrong it's because of "circular reference".
:-)
In the above case all script-side references to DIV are in that
instance of customDIV. Remove relevant DIV, then remove the instance
itself, wait for garbage collector to clear the heap.
Most of "circular reference" cases are caused by wrong idea of how
garbage collector works. Again: the memory may be freed up in 1sec, in
10sec, in 5min or *never* during the current browser session which is
totally correct for Java-like memory management.

[VK]

Richard Cornford wrote:

<snip>

function showID() {
alert(this.$.$.id);
You silly sod.

Thinking over it: Indeed.
You have tied yourself up in knots so much that you
cannot see that - this.$.$.id - is exactly the same as - this.id -.

Indeed.

Thank you.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

<snip>

> function showID() {
> alert(this.$.$.id);

You silly sod.

Thinking over it: Indeed.

You have tied yourself up in knots so much that you
cannot see that - this.$.$.id - is exactly the same as - this.id -.

Indeed.

Yes, indeed. Haven't you figured it out yet; I am one of the people on
this group who do understand how javascript works in considerable
technical detail. I understand what the code you write does considerably
better than you do. I may not always be correct (to err is human) but
when I say something is so the odds are very good that it is so. So
declaring me wrong without checking is only going to make you look
foolish.

Richard.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

Nobody in their right mind would take your proclamations
on what is, or is not, cross-browser seriously.
No one have to believe VK. Believe to your own eyes: the
code is here. Simply compare screen redraw behavior with
test and test2.

The proclamation you made (and edited out of your quote) was:-

| it's a cross-browser behavior so this cannot be true.

- and as we already know you only have a slight (and often erroneous)
familiarity with two or three browsers your generalisations about
browsers and you labelling anything as cross-browser cannot be taken
seriously.

How well any code you posted satisfies your vague criteria for 'works'
does not alter the validity of your opinions about web browsers.

<snip>

> function showID() {
> alert(this.$.$.id);

You silly sod. You have tied yourself up in knots so much
that you cannot see that - this.$.$.id - is exactly the same
as - this.id -.

No - read the code right.

I did read the code. I was struck by how needlessly obscure and
convoluted it was for no good reason, and so reminded that you
pontificate on the cost-effectiveness and business aspects of web
development while writing code that imposes a massive maintenance burden
on whoever purchases.

I also understood your code, obviously better than you did. Which again
speaks to the maintenance aspects of your code. When you don't actually
understand what you are writing how are you going to effectively
document it? So you have needlessly complicated, obscure and convoluted
code with inaccurate documentation (where inaccurate documentation if
potentially more harmful than no documentation at all). This is what
makes you an absolute liability as a programmer; an ongoing burden to
anyone fool enough to employ you. It is no wonder you prefer to post to
Usenet anonymously.
The constructor returns augmented div
itself, not a JavaScript object.
Which construct? this.$.$.id - evaluates as a property of a DOM element;
either a string primitive value or the undefined value.

> function customDIV(id) {
> this.$ = document.createElement('DIV');
> this.$.$ = this;

<snip>

Obscure, convoluted and one of the shortest
circular references including a DOM node possible.

That "circular reference" is a real bogeyman of JavaScript
recently :-)

Not really. An awareness of the IE memory leak problem is now becoming
mainstream but it has been the subject of investigation, discussion and
solution-design on this group for 3 years or so. That is the way things
normally work as the cutting edge of javascript development happens here
and it takes some time for it to filter out to the mainstream.

Of course you won't be aware of this as interesting discussions go on so
far over your head that you cannot even perceive that they are
happening.
Every time something goes wrong it's because of "circular
reference". :-)
So you don't understand this issue either, I didn't think you did.
In the above case all script-side references to DIV are
in that instance of customDIV. Remove relevant DIV, then
remove the instance itself, wait for garbage collector to
clear the heap.
But you don't know how to remove all references.
Most of "circular reference" cases are caused by wrong idea
of how garbage collector works.
Bullshit!
Again: the memory may be freed up in 1sec, in
10sec, in 5min or *never* during the current browser
session which is totally correct for Java-like memory
management.

When you don't understand what you are talking about you would look less
of a fool by staying silent.

Richard.