473,387 Members | 1,545 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 software developers and data experts.

connot set handlers on XMLHttpRequest instance in FF1.5

I have the following code running in FireFox 1.5 (a remote XUL
application):

var req = new XMLHttpRequest();
// execution will block until request is
completed
// third param set to false makes request
synchronous
req.open(strMethod, uriTarget, false);
if(strMethod == "POST") {

req.setRequestHeader('Content-Type','application/x-www-form-urlencoded;
charset=UTF-8');
}
req.onreadystatechange = function () {
if (req.readyState == 4) {
if(req.status == 200) {
strResult = req.responseText;
xmlResult = req.responseXML;
}
else {
strLastError = uriTarget + " returned http error code " +
req.status + "\n" + req.statusText;
if(intVerbosity > 1) throw new Error(strLastError);
}
}
}
req.onerror = function() {
strLastError = uriTarget + " fetch failed while " +
arrReadyState[req.readyState];
if(intVerbosity > 1) throw new Error(strLastError);
}
req.send(strRequest);

By the time it gets to req.send() (at the bottom) all the callback
functions like req.onerror still have values of null. I've verified
this using the Venkman debugger with req as a watch variable.

the code is clearly assigning functions to those callback function
objects. Any idea why they are all turning up null?

No errors are showing up in the JS console.

Dec 23 '05 #1
8 1327
Spasmoid wrote:
I have the following code running in FireFox 1.5 (a remote XUL
application):

var req = new XMLHttpRequest();
// execution will block until request is
completed
// third param set to false makes request
synchronous
Code should be posted (and written in the first place) so that it is not
subject to potential word-wrap, that is, it should not exceed 80 characters
per line.
req.open(strMethod, uriTarget, false);
[...]
req.onreadystatechange = function () {
[...]
}
req.onerror = function() {
[...]
}
req.send(strRequest);

By the time it gets to req.send() (at the bottom) all the callback
functions like req.onerror still have values of null.

I've verified this using the Venkman debugger with req as a watch
variable.

the code is clearly assigning functions to those callback function
objects. Any idea why they are all turning up null?


`onreadystatechange' is for asynchronous requests only. I do not
know why `onerror' is `null' even if you assigned a value to it;
that may have to do with the synchronous request as well.

<URL:http://xulplanet.com/references/objref/XMLHttpRequest.html>
HTH

PointedEars
Dec 23 '05 #2
Ahh yeah. Forgot about that. Thanks for reminding me.
Dum mistake :(

I will try to remember to make the code post friendly next time.

Dec 23 '05 #3
Thomas 'PointedEars' Lahn said the following on 12/22/2005 8:18 PM:
Spasmoid wrote:

I have the following code running in FireFox 1.5 (a remote XUL
application):

var req = new XMLHttpRequest();
// execution will block until request is
completed
// third param set to false makes request
synchronous

Code should be posted (and written in the first place) so that it is not
subject to potential word-wrap, that is, it should not exceed 80 characters
per line.


To state that code should be written at less than 80 characters per line
is ludicrous. There is no limitation in the language that even makes
that remotely related.

If your text editor wraps code at 80 characters, you don't need to
change your coding style, you need to change text editors.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 23 '05 #4
Randy Webb <Hi************@aol.com> writes:
To state that code should be written at less than 80 characters per
line is ludicrous. There is no limitation in the language that even
makes that remotely related.
No, it is a limit in some, widely used, newsreaders, that they
automatically and unavoidably breaks lines longer than 80 characters
both when sending and receiving. I.e., The limit is not on code in
general, but on code to be posted to a newsgroup.

Shorter lines are recommended because it is easier to make people
write shorter lines than it is to make them use a newsreader that
doesn't munge longer lines - although in the long run, that would
be best for them.
If your text editor wraps code at 80 characters, you don't need to
change your coding style, you need to change text editors.


And when your newsreader breaks longer lines, you need to write
shorter lines when asking for help with your code, because the code
you post is not going to work otherwise. Sure, anybody competent
enough to help with the problem can probably also fix the improper
line breaks, but it adds extra work that will surely make some
readers, myself included, reconsider whether I don't have something
better to spend my time on (yeah right, but in theory :).

/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.'
Dec 24 '05 #5
JRS: In article <qL********************@comcast.com>, dated Thu, 22 Dec
2005 22:32:44 local, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :
Thomas 'PointedEars' Lahn said the following on 12/22/2005 8:18 PM:

Code should be posted (and written in the first place) so that it is not
subject to potential word-wrap, that is, it should not exceed 80 characters
per line.


To state that code should be written at less than 80 characters per line
is ludicrous. There is no limitation in the language that even makes
that remotely related.

If your text editor wraps code at 80 characters, you don't need to
change your coding style, you need to change text editors.

Code that is written to be read in Usenet News should be written,
whenever practicable (as it always is in javascript) with no more than
72 characters per line, since that is the accepted Usenet norm. Not 80;
not even 76, as called for by the fascist bully-boy, but 72.

Code that has not been written for News, but needs to be posted to News,
must not be machine-wrapped by the posting agent; it may be manually &
sensibly wrapped (in which case it should be re-tested before posting),
or it may be posted with longer lines.

A reader agent that cannot display longer lines faithfully is defective,
and should not be pandered to.

A text editor should wrap lines at the setting that its user chooses,
over a wide range of widths including 80.

Material to be read as text should be wrapped at about 72, even if code
is longer.

A copy of <URL:http://www.merlyn.demon.co.uk/js-quick.htm> can wrap
paragraphs to selected width - range (IIRC) 1 to enormous - though it
may not work if line-endings are not CRLF.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of 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.
Dec 24 '05 #6
Lasse Reichstein Nielsen said the following on 12/24/2005 8:55 AM:
Randy Webb <Hi************@aol.com> writes:

To state that code should be written at less than 80 characters per
line is ludicrous. There is no limitation in the language that even
makes that remotely related.

No, it is a limit in some, widely used, newsreaders, that they
automatically and unavoidably breaks lines longer than 80 characters
both when sending and receiving. I.e., The limit is not on code in
general, but on code to be posted to a newsgroup.


The implication that I got from the statement that you snipped was that
one should code at less than 80 characters. Now, that is well true for
posting code, but it is ludicrous to state that about writing code in
general.
Shorter lines are recommended because it is easier to make people
write shorter lines than it is to make them use a newsreader that
doesn't munge longer lines - although in the long run, that would
be best for them.
But that still has no bearing on how I should/would write code that was
never to be posted to Usenet.
If your text editor wraps code at 80 characters, you don't need to
change your coding style, you need to change text editors.


And when your newsreader breaks longer lines, you need to write
shorter lines when asking for help with your code, because the code
you post is not going to work otherwise. Sure, anybody competent
enough to help with the problem can probably also fix the improper
line breaks, but it adds extra work that will surely make some
readers, myself included, reconsider whether I don't have something
better to spend my time on (yeah right, but in theory :).


I totally agree. But that was not my point about what he said. Re-read
what he posted and my reply. My reply is about coding in general, you
are referring to code posted to Usenet.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 25 '05 #7
Dr John Stockton said the following on 12/24/2005 11:57 AM:
JRS: In article <qL********************@comcast.com>, dated Thu, 22 Dec
2005 22:32:44 local, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :
Thomas 'PointedEars' Lahn said the following on 12/22/2005 8:18 PM:
Code should be posted (and written in the first place) so that it is not
subject to potential word-wrap, that is, it should not exceed 80 characters
per line.


To state that code should be written at less than 80 characters per line
is ludicrous. There is no limitation in the language that even makes
that remotely related.

If your text editor wraps code at 80 characters, you don't need to
change your coding style, you need to change text editors.


Code that is written to be read in Usenet News should be written,
whenever practicable (as it always is in javascript) with no more than
72 characters per line, since that is the accepted Usenet norm. Not 80;
not even 76, as called for by the fascist bully-boy, but 72.


Agreed - with respect to Usenet.
Code that has not been written for News, but needs to be posted to News,
must not be machine-wrapped by the posting agent; it may be manually &
sensibly wrapped (in which case it should be re-tested before posting),
or it may be posted with longer lines.
Agreed - with respect to Usenet.
A reader agent that cannot display longer lines faithfully is defective,
and should not be pandered to.

A text editor should wrap lines at the setting that its user chooses,
over a wide range of widths including 80.
Material to be read as text should be wrapped at about 72, even if code
is longer.


None of which I was pointing out. The problem is his implication that
one should *always* write code at less than ~72 characters. And that is,
well, ludicrous :)

It is not until code is introduce to Usenet that it's line length's
become relevant.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 25 '05 #8
Randy Webb <Hi************@aol.com> writes:
I totally agree. But that was not my point about what he said. Re-read
what he posted and my reply. My reply is about coding in general, you
are referring to code posted to Usenet.


While I can see that you can read Mr Lahn's original answer to refer
to all code, I could also understand it as only referring to the code
that is to be posted. Picking one reading of the posting and calling
it ludicrous, instead of just pointing out that the wording is less
than precise and making it precise, makes more noise than is necessary.

It also feels somewhat disingenious, perhaps because it seems that
several people are going out of their way to find flaws in each
others' postings, just because the poster is who he is.

I perfectly understand the feeling of wanting to rub someone's nose in
every little error they might make, but personal vendettas are not
endearing, and they do lower the perceived credibility of whoever
pursues them.

/L 'never argue with idiots, they merely bring you down to their
level, then beat you with experience'
--
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.'
Dec 25 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Henri Sivonen | last post by:
I got the following error: Error: " nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" .... with Firefox when using XMLHttpRequest. What's happenening? Is the object being garbage collected...
10
by: Matt Kruse | last post by:
I'm aware of the circular reference memory leak problem with IE/closures. I'm not sure exactly how to resolve it in this situation. Also, Firefox appears to grow its memory size with the same code....
5
by: Rufnex | last post by:
Hi, is it possible to use the XMLHTTPRequest-Object with the Methods PUT and DELETE in JavaScript? Maybe there is a tutorial or a short e.g. thx for answer Rufnex
3
by: Diffident | last post by:
I am trying to use XMLHttpRequest on the IE browser of a MAC machine. It throws me a javascript error which reads as "Object doesn't support this action" while trying to create an instance of the...
42
by: Greg | last post by:
Hi, I've designed a bookmark in Ajax / PHP that I will put soon on sourceforge.net. But I've got an very tricky bug. I try it on some computers with Internet Explorer/Windows, Firefox...
7
by: pamelafluente | last post by:
The precious input given by Laurent, Martin, Benjamin about XMLHttpRequest in Javascript, has made me think that perhaps I could improve what I am currently doing by using Ajax. Let's make it...
27
by: arkmancn | last post by:
Any comments? thanks. Jim
3
by: George | last post by:
I am doing an AJAX call using JQuery on my page to which returns JSON objects and everything works fine. Now I decided to use ashx handler instead of and simply write JSON out. Then my problems...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.