Aha!

I had a feeling it must be either readyState or status.... IE6's
XMLHttpRequest object is some funky activeX component... IE7 introduced it
as a plain javascript object.

anytime you see xhr.ANYTHING, that should be a red flag that it might not
work in IE6, and you'll need a try/catch or some other workaround.




On Mon, May 25, 2009 at 5:19 AM, Zach Anderson <[email protected]>wrote:

>
> It looks like the xhr.status is actually what's causing the error in
> IE6. My guess would be it's just not returning a status correctly (or
> at least consistently with the other browsers) and that's causing your
> error. This might be a difference with the ActiveX object being used
> instead of the native browser support (XMLHttpRequest) but that again
> is just a guess. I don't have all my goodies with me to test it out.
>
> If you replace
>
> document.getElementById("updateArea").innerHTML = currMsg + "<p>The
> current state is " + xhr.readyState + " and the status is " +
> xhr.status + "</p>";
>
> with
>
> document.getElementById("updateArea").innerHTML = currMsg + "<p>The
> current state is " + xhr.readyState + "</p>";
>
> The script will run although you may not get the exact results you're
> expecting. Browsers have gotten better about going through the
> readyState's as expected, but there were differences... here's an
> older article covering some of them
>
> http://www.quirksmode.org/blog/archives/2005/09/xmlhttp_notes_r_2.html
>
> In a real world setting, I've never done any useful with any
> readyState but 4 (ready or completed) so the differences seem to be
> pretty academic. Maybe someone else could give an example of a time
> where other states were needed?
>
> Also, regarding IE6 support, it still seems to be used by 15-35% of
> users, depending on your audience. So, at least for myself, it seems
> worth supporting it for the time being for public facing projects. If
> you spend the (noble) time and effort to make something function and
> usable for a tiny percentage using screen readers or other assistive
> devices, it would make sense to spend the same effort for a huge
> percentage of users that simply don't know or have any control over
> the fact that their browser is out of date.
>
> Good luck with the learning and welcome.
>
> Zach
>
> On May 24, 5:52 pm, kaffeen <[email protected]> wrote:
> > Hello,
> >
> > Thanks for the suggestions/comments everyone. I agree that IE6 is dated,
> but
> > I would like to at least *try* to support it.
> >
> > Plus, regardless of IE version, unexpected behavior really bothers me
> unless
> > I can figure it out. It is a bit of a game to me as well. I have
> primarily
> > been an application developer for the last 10 years. In my particular
> field,
> > web services were not practical in the past. That is quickly changing and
> I
> > want to update my skills as well. Hence, learning web stuff that I have
> come
> > across in the past, but just not spent a great deal of time with.
> >
> > Adam, the suggestions below did not work. Thanks for the ideas though.
> >
> > If anyone wants to take a crack at it, this is the script.html file.
> >
> > <html>
> > <head>
> >     <title>The Simplest Ajax Script</title>
> >     <script type="text/javascript" src="script.js">
> >     </script>
> > </head>
> > </body>
> >     <div id="updateArea">&nbsp;</div>
> > </body>
> > </html>
> >
> > And here is the complete script.js referenced by script.html (don't worry
> > about colors.xml, it is not really needed, you'll just get a 404 instead
> of
> > 200 if nothing there)....
> >
> > window.onload = makeRequest;
> > var xhr = false;
> >
> > function makeRequest() {
> >     if (window.XMLHttpRequest) {
> >         xhr = new XMLHttpRequest();
> >     }
> >     else {
> >         if (window.ActiveXObject) {
> >            try {
> >                xhr = new ActiveXObject("Microsoft.XMLHTTP");
> >            }
> >            catch (e) {}
> >         }
> >     }
> >
> >     if (xhr) {
> >         xhr.onreadystatechange = showState;
> >         xhr.open("GET", "colors.xml", true);
> >         xhr.send(null);
> >     }
> >     else {
> >         document.getElementById("updateArea").innerHTML = "Sorry, but I
> > couldn't create an XMLHttpRequest";
> >     }
> >
> > }
> >
> > function showState() {
> >     var currMsg = document.getElementById("updateArea").innerHTML;
> >     document.getElementById("updateArea").innerHTML = currMsg + "<p>The
> > current state is " + xhr.readyState + " and the status is " + xhr.status
> +
> > "</p>";
> >
> > }
> >
> > If you run it on FF you will see states 2, 3, and 4. If you run it on
> IE6,
> > you'll see just state 4 and an error.
> >
> > Regards,
> >
> > ~K
> >
> > On Sun, May 24, 2009 at 3:33 PM, Adam Theriault <[email protected]
> >wrote:
> >
> >
> >
> > > Just to be clear, heres' the two things I'd try:
> >
> > > function showState() {
> > > var xhr = new XMLHttpRequest();
> > >     currMsg = document.getElementById(" updateArea").innerHTML;
> > >     document.getElementById("updateArea").innerHTML = currMsg + "<p>The
> > > current state is " + xhr.readyState + " and the status is " +
> xhr.status +
> > > "</p>";
> > > }
> >
> > > if that doesn't work, try
> >
> > > function showState() {
> > > var xhr = new XMLHttpRequest();
> > >     currMsg = document.getElementById(" updateArea").innerHTML;
> > >     document.getElementById("updateArea").innerHTML = currMsg;
> > > }
> >
> > > if the first one works, great, if not, and the second one works, you'll
> > > have to decide what you want to do with IE6. You can create an
> exception
> > > using the try/catch statement.... info on that is here:
> >
> > >http://www.w3schools.com/jS/js_try_catch.asp
> >
> > > hope this helps.
> >
> > > On Sun, May 24, 2009 at 3:31 PM, Adam Theriault <[email protected]
> >wrote:
> >
> > >> I should point out that most JS frameworks support IE6, due to IE
> users
> > >> being sluggish on adoption rate for a myriad of reasons.
> >
> > >> That'll probably start to fall off pretty quickly when rumors of IE9
> start
> > >> popping up, and major sites change their previous-current-next support
> > >> scheme to cover ie7-9 rather than the current 6-8.
> >
> > >> As Paul said, seeing it in context would help, but shot in the dark:
> > >> s*ince that second line is one big value assignment, I'm guessing what
> it
> > >> might really have a problem with is:
> >
> > >> xhr.readyState
> >
> > >> your starting a function, but not defining "xhr" in the function
> scope,
> > >> and it doesn't look like any variables are getting passed to the
> function.
> >
> > >> I'm guessing somehwere else in the code, you've got something like:
> >
> > >> *var xhr* = new *XMLHttpRequest*();
> >
> > >> move that inside this function and see if that helps.
> >
> > >> Also, top of my head, but IE6 doesn't support a lot of
> XMLHttpRequest's
> > >> methods...so in addition to "xhr" being a potential problem here,
> > >> "readyState" might also be...I don't recall off the top of my head
> though.
> >
> > >> Try removing that whole line, and if the function works okay, you know
> > >> it's one half or the other.
> >
> > >> -a
> >
> > >> On Sun, May 24, 2009 at 2:05 PM, Paul <[email protected]> wrote:
> >
> > >>> Kaffeen,
> > >>> Can you provide a URL to the page in question. Might be easier to
> help if
> > >>> we can take a look at it.
> >
> > >>> Also, I sort of agree with the comment from Doug. Using a JS
> framework (I
> > >>> prefer jQuery) rather than hand coding. Though not impossible. Just
> better
> > >>> cross-browser handling via a framework. Not going to comment on the
> IE6
> > >>> thing.
> >
> > >>> P-
> >
> > >>> On May 24, 2009, at 11:15 AM, kaffeen wrote:
> >
> > >>> First, I'm not sure if this group would be the correct one to use for
> > >>> this type of question. I've not really actively participated in this
> group,
> > >>> although I do read it frequently. My apologies if this is not the
> place for
> > >>> this, please let me know.
> >
> > >>> Second, I have a bug in IE that I cannot seem to figure out. It is
> > >>> actually from a course on Lynda.com. I've not had much experience
> with Ajax,
> > >>> so I am taking one of those lessons there. This particular section of
> the
> > >>> lesson is related to the different states and status.
> >
> > >>> The bug is related to the following snippet of code...
> >
> > >>> function showState() {
> > >>>     currMsg = document.getElementById("updateArea").innerHTML;
> > >>>     document.getElementById("updateArea").innerHTML = currMsg +
> "<p>The
> > >>> current state is " + xhr.readyState + " and the status is " +
> xhr.status +
> > >>> "</p>";
> > >>> }
> >
> > >>> Basically, this is just updating the browser with the status. In
> Firefox,
> > >>> it works fine and the output is as follows:
> >
> > >>> *The current state is 1 and the status is 200*
> >
> > >>> *The current state is 2 and the status is 200*
> >
> > >>> *The current state is 3 and the status is 200*
> >
> > >>> *The current state is 4 and the status is 200*
> >
> > >>> In IE 6, I get this result (with an error):
> >
> > >>> *The current state is 4 and the status is 200*
> >
> > >>> If I examine the error, it is basically complaining about the
> > >>> document.getElementById("updateArea").innerHTML
> >
> > >>> IE6 does not report any of the 1, 2, or 3 states.
> >
> > >>> I don't have a Premium membership to Lynda, so it is quite possible
> there
> > >>> is a typo there, but I can't find it and it works fine with FF. In
> addition,
> > >>> I have googled this and found some things to try and interesting
> information
> > >>> about innerHTML and element/id bugs with IE, however, at this time,
> nothing
> > >>> has really resolved this particular error for me.
> >
> > >>> If anyone understands this bug/error, please let me know how to
> correct
> > >>> in IE.
> >
> > >>> Kind Regards,
> >
> > >>> Kaffeen
> >
> > >>> -- If you understand, things are just as they are. If you do not
> > >>> understand, things are just as they are.
> >
> > --
> > If you understand, things are just as they are. If you do not understand,
> > things are just as they are.
> >
>

--~--~---------~--~----~------------~-------~--~----~
Our Web site: http://www.RefreshAustin.org/

You received this message because you are subscribed to the Google Groups 
"Refresh Austin" group.

[ Posting ]
To post to this group, send email to [email protected]
Job-related postings should follow http://tr.im/refreshaustinjobspolicy
We do not accept job posts from recruiters.

[ Unsubscribe ]
To unsubscribe from this group, send email to 
[email protected]

[ More Info ]
For more options, visit this group at 
http://groups.google.com/group/Refresh-Austin
-~----------~----~----~----~------~----~------~--~---

Reply via email to