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. 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
Ahh yeah. Forgot about that. Thanks for reminding me.
Dum mistake :(
I will try to remember to make the code post friendly next time.
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/
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.'
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.
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/
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/
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.' This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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....
|
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
|
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...
|
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...
|
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...
|
by: arkmancn |
last post by:
Any comments? thanks.
Jim
|
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...
|
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,...
|
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$) {
}
...
|
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...
|
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
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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...
|
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...
|
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,...
|
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...
| |