Instantiating XHR (Code Worth Recommending Project)
Peter Michaux
confusing. I have seen all of the following in various places and I
have seen the string argument with various captializations.
new ActiveXObject('Microsoft.XMLHttp')
new ActiveXObject('MSXML2.XMLHttp')
new ActiveXObject('MSXML2.XMLHttp.3.0')
new ActiveXObject('MSXML2.XMLHttp.4.0')
new ActiveXObject('MSXML2.XMLHttp.5.0')
new ActiveXObject('MSXML2.XMLHttp.6.0')
It seems as though ActiveXObject is case insensitive to its argument.
I have looked but cannot find documentation to support this. Does
anyone know where Microsoft states this?
Deciding which argument(s) to try is confusing. Even the Microsoft
people don't agree:
From Microsoft's XML team's blog
<URL: http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx>
From Microsoft's IE team blog
<URL: http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx>
What I gather from the above two pages is the following.
"Microsoft.XMLHTTP" is for legacy. This may be implemented in MSXML3
as a synonym for legacy support. A computer that only has MSXML3
installed will still function. Knowing if the two are synonyms is
important.
"Msxml2.XMLHTTP.2.0" should be avoided???
"Msxml2.XMLHTTP.3.0" and "Msxml2.XMLHTTP" may be synonymous and are on
all OS from fully patched Win2k SP4 and up
"Msxml2.XMLHTTP.4.0" was never released with an OS and completely
superseeded by MSXML6
"Msxml2.XMLHTTP.5.0" is for use with Microsoft Office only
"Msxml2.XMLHTTP.6.0" is the new standard that may have some advantages
over older versions but maybe not for the XHR object.
Testing that a page that uses an ActiveX XHR object requires testing
on a variety of computers that have certain dll files corresponding to
the arguments tried when instantiating the ActiveXObject. Keeping the
number of arguments tried to a minimum reduces the number of dll files
that need to be tested. To determine which dlls are installed on the
computer look in System32 folder to find files like "msxml3.dll"
The IE blog recommends using Microsoft.XMLHTTP and the XML team blog
recommends using MSXML2.XMLHttp.3.0. My guess is the XML team is not
thinking like a browser script programmer that is worried about
backwards compatability.
A page about this by Martin Honnen
<URL: http://www.faqts.com/knowledge_base/view.phtml/aid/35742>
--------------------------------------
The following function would be the maximum function that could be
used if MSXML 4 and 5 should not be used. It doesn't test the
abilities of the XHR but just sets a function that is capable of
instantiating an XHR. A function that will use XHR objects must
determine if XHR in the browser has the necessary set of abilities for
the function. '
var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// for legacy eg. IE 5
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// for fully patched Win2k SP4 and up
// next line may be useless and just a synonym for
// the Microsoft.XMLHTTP factory above
function() {
return new ActiveXObject("Msxml2.XMLHTTP.3.0");
},
// IE 6 users that have updated their msxml dll files.
function() {
return new ActiveXObject("Msxml2.XMLHTTP.6.0");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];
// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs[i]()) {
return fs[i];
}
}
catch (e) {}
}
})();
---------------
The minimum function would be the following
var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// IE 6-
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];
// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs[i]()) {
return fs[i];
}
}
catch (e) {}
}
})();
Of course both of the above can be included in the repository. What
I'd like to know is if there is any advantage at all by using the
longer version.
--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca/
VK
> Instantiating an XMLHttpRequest object in Internet Explorer is a bit
> confusing.
The confusion originates from a highly confused - yet currently
standard de facto - usage of IXMLHTTPRequest (that became
XmlHttpRequest on others, "ajaxoid" any further in this post for
brevity if referring in general for all browsers). IXMLHTTPRequest is
an iternal XML tool used in Microsoft solutions for data binding. In
the most simple way one has a DOM node (div, table cell, table -
whatever) client-side and static or dynamic data source server-side.
By using data binding commands/attributes one creates binding between
DOM nodes and a data fields in the said source. After all bindings are
set, all you have to do is to issue new send() requests: the necessary
page updates are going automatically ondataavailable. This very time
and resource effective solution exists since IE4 on Windows platforms.
Alas the adaptation of ajaxoid is gone in a completely different
direction. Basically after the "discover" it was used as some "XXIst
century cool and advanced" replacement for the age old form
target="HiddenFrame" trick. So developers have chosen to use ajaxoid
as a manually driven transport for data retrieval from the server with
further manual data handling and page update. This btw answers the
frequent question "what are the advantages of ajaxoid over hidden
frame submission?". The answer is: "In the spelled above misuse there
are not any. Ajaxoid is even much lesser functional than hidden frame
submission because it cannot handle input type="file".
How is interested may also read mine and others' post of the year 2005
thread "what's wrong with ajax?":
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f6ce0a5e95d8bf30
Now coming back to the original question of XMLHTTP versioning. If the
ajaxoid is "standardly misused" as a hidden browser to get textual
data from the server then it is irrelevant what version to use: any
will go. In this case it is better to stick to the universal alias
"Microsoft.XMLHTTP", that covers anything from IE4 till now. If the
ajaxoid is really used for XML data handling then it may be important
to know what XMLHTTP version is available: or not important - it all
depends on what XML features and XPath commands are used. There cannot
be any general suggestions besides two:
1) Check for used XML features and XPath commands availability to know
the lowest supported XMLHTTP version.
2) If fall-back goes up to XMLHTTP 3.0 inclusive and if it's the only
one available on the client - then don't forget to switch the default
language from XSLPattern to XPath. For any older version XPath is by
default.
From the source reliability point of view the linked MSDN blog has
higher value over anything else because it is written by guy(s) who
really making MSXML:
http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx
There are more useful info in my discussion with the blog author at
microsoft.public.xml
http://groups.google.com/group/microsoft.public.xml/browse_frm/thread/7772ac2ad016e2bf
VK
For any _newer_ version of course...
Peter Michaux
> On Dec 14, 2:35 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Instantiating an XMLHttpRequest object in Internet Explorer is a bit
> > confusing.
>
> The confusion originates from a highly confused - yet currently
> standard de facto - usage of IXMLHTTPRequest (that became
[snip]
The Google Groups interface seems to think that Thomas "PointedEars"
Lahn has replied to this post but the body of Thomas' post does not
appear unfortunately.
VK
> The Google Groups interface seems to think that Thomas "PointedEars"
> Lahn has replied to this post but the body of Thomas' post does not
> appear unfortunately.
Yes, I noticed it as well. I hope that Thomas will not take it as some
nasty VK's conspiracy :-)
David Mark
]snip]
This looks right to me. As mentioned, the four unique MS
implementations (three ActiveX) have differences. One is that IE7's
take on XMLHttpRequest does not support the overrideMimeType crutch.
> ---------------
>
> The minimum function would be the following
>
> var createXMLHttpRequest = (function() {
> var xhr,
> i,
> fs = [// IE 6-
> function() {
> return new ActiveXObject("Microsoft.XMLHTTP");
> },
> // IE7, Safari, Mozilla, Opera, etc
> function() {
> return new XMLHttpRequest();
> }];
>
> // Loop through the possible factories to try and find one that
> // can instantiate an XMLHttpRequest object that works.
> for (i=fs.length; i--; ) {
> try {
> if (fs[i]()) {
> return fs[i];
> }
> }
> catch (e) {}
> }
>
> })();
This should be sufficient for most applications and is less ambiguous.
>
> Of course both of the above can be included in the repository. What
> I'd like to know is if there is any advantage at all by using the
> longer version.
None that I know of.
Thomas 'PointedEars' Lahn
> On Dec 14, 3:48 am, VK <schools_r...@yahoo.com> wrote:
>> On Dec 14, 2:35 am, Peter Michaux <petermich...@gmail.com> wrote:
>>> Instantiating an XMLHttpRequest object in Internet Explorer is a bit
>>> confusing.
>> The confusion originates from a highly confused - yet currently
>> standard de facto - usage of IXMLHTTPRequest (that became
>
> [snip]
>
> The Google Groups interface seems to think that Thomas "PointedEars"
> Lahn has replied to this post
Which actually happened.
> but the body of Thomas' post does not appear unfortunately.
Not using Google's faulty Web interface, unless one temporarily has to,
might be the solution to this problem. Besides the mentioned bug, for
example, your signature is broken; it has to be delimited with "-- "
(followed by CRLF), and it is delimited with "--" (followed by CRLF).
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
VK
wrote:
> Not using Google's faulty Web interface, unless one temporarily has to,
> might be the solution to this problem.
Or using a descent NNTP server for posting: in my memory this is the
first time ever in Google Groups the title is displayed but no body.
Also my free two free NNTP servers I am using as a reserve one missed
the post completely, other reported the same header w/o body. Someone
is playing hard with message headers I guess (?)
Anyway I have gotten the post over developersdex mirror:
http://www.developersdex.com/asp/message.asp?p=2978&r=6080012
Nothing really interesting to argue with productively but thanks for
correcting the typo: XMLHttpRequest, not "XmlHttpRequest". The object
name is using broken camel-case schema - I guess to stress out on XML.
Thomas 'PointedEars' Lahn
> Anyway I have gotten the post over developersdex mirror:
> http://www.developersdex.com/asp/message.asp?p=2978&r=6080012
>
> Nothing really interesting to argue with productively
You are a sorry excuse for a participant in a discussion. What I posted is
nothing that you could reasonably debate as I stated the facts (about much
more than just XMLHttpRequest) while you only boldly posted your fantasy
again. At least you could stand corrected for that.
> but thanks for correcting the typo: XMLHttpRequest, not "XmlHttpRequest".
You're welcome.
> The object name is using broken camel-case schema
1. Reference identifier, not name.
2. If camel-case naming was a requirement defined by a standard, only then
using the word "broken" for different naming would be appropriate.
> - I guess to stress out on XML.
Not understood.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Dr J R Stockton
16 Dec 2007 14:06:01, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
>Not using Google's faulty Web interface, unless one temporarily has to,
>might be the solution to this problem. Besides the mentioned bug, for
>example, your signature is broken; it has to be delimited with "-- "
>(followed by CRLF), and it is delimited with "--" (followed by CRLF).
>
Since you evidently do not yourself understand how a signature should be
constructed, as you have repeatedly been told, you are once again
demonstrating your truly obnoxious personality.
--
(c) John Stockton, Surrey, UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] posted:
>> Not using Google's faulty Web interface, unless one temporarily has to,
>> might be the solution to this problem. Besides the mentioned bug, for
>> example, your signature is broken; it has to be delimited with "-- "
>> (followed by CRLF), and it is delimited with "--" (followed by CRLF).
>
> Since you evidently do not yourself understand how a signature should be
> constructed, as you have repeatedly been told, you are once again
> demonstrating your truly obnoxious personality.
I have explained what is technically required for a signature as it is
understood for Usenet messages and by properly working newsreader software,
which is not met here. Anything else follows merely from your ongoing
misinterpretation of recommendations and even Internet drafts as standards:
As long as I have a line in my posting containing only "-- " (+CLRF), what
follows qualifies as a signature; it is a signature that follows universally
accepted Usenet guidelines if it is not more than four lines. What is above
that delimiter is _not_ part of the signature, and as such it is only by its
format, and not by its content, subject of any (quasi-)standard. (And that
format as defined in RFC1036 was obeyed.)
To be precise, if I do not want to make my (nick)name-signature part of the
signature as that is technically understood (for example, in order to keep
the signature short!), I am absolutely free to do so, and removing it is for
readers not any harder than snipping any other part of any other posting.
And if I do not want to put contact information in my signature but a
randomly selected text instead, like evidently a number of other Usenet
participants, many of them being regulars, do, I am absolutely free to do
so, even though I would not follow the evidently rather outdated
corresponding recommendation in RFC1855, then.
If you want to bother someone about their postings not conforming to
(quasi-)standards, why don't you start with bothering the large number of
incompetent anti-social people who help to break the medium as a means of
building a social network by using non-existing e-mail addresses in address
headers, a clear violation of RFC1036 and STD11 (obsoleted by RFC2822)?
EOD
Peter Michaux
> On Dec 16, 4:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > Not using Google's faulty Web interface, unless one temporarily has to,
> > might be the solution to this problem.
>
> Or using a descent NNTP server for posting: in my memory this is the
> first time ever in Google Groups the title is displayed but no body.
> Also my free two free NNTP servers I am using as a reserve one missed
> the post completely, other reported the same header w/o body. Someone
> is playing hard with message headers I guess (?)
>
> Anyway I have gotten the post over developersdex mirror:http://www.developersdex.com/asp/message.asp?p=2978&r=6080012
Thanks.
Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
XMLHTTP version
installed on the client system." and I believe that is not true based
on things I've been reading lately. Can Thomas' claim be
substantiated?
Thomas 'PointedEars' Lahn
> Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
> XMLHTTP version installed on the client system." and I believe that
> is not true based on things I've been reading lately.
Without you naming then things you are referring to, I may as well
say I didn't believe you either. That's a great style of discussion,
isn't it?
> Can Thomas' claim be substantiated?
Create the object, check the properties it provides and cross-check
with the version information for that property in the MSDN Library.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Peter Michaux
wrote:
> Peter Michaux wrote:
> > Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
> > XMLHTTP version installed on the client system." and I believe that
> > is not true based on things I've been reading lately.
>
> Without you naming then things you are referring to, I may as well
> say I didn't believe you either. That's a great style of discussion,
> isn't it?
It isn't optimal.
> > Can Thomas' claim be substantiated?
>
> Create the object, check the properties it provides and cross-check
> with the version information for that property in the MSDN Library.
Is there Microsoft documentation to substantiate your claim? I have
not seen any and I have been reading about this on the Microsoft site.
The only thing I've seen is in the XML blog post link I posted in the
first post of this thread. It says that if MSXML3.dll (or whatever it
is called) is installed then Microsoft.XMLHTTP will use it. I have not
seen that if MSXML6.dll (or whatever it is called) is installed that
Microsoft.XMLHTTP should be used.
Randy Webb
> Dr J R Stockton wrote:
>> [...] Thomas 'PointedEars' Lahn [...] posted:
>>> Not using Google's faulty Web interface, unless one temporarily has to,
>>> might be the solution to this problem. Besides the mentioned bug, for
>>> example, your signature is broken; it has to be delimited with "-- "
>>> (followed by CRLF), and it is delimited with "--" (followed by CRLF).
>> Since you evidently do not yourself understand how a signature should be
>> constructed, as you have repeatedly been told, you are once again
>> demonstrating your truly obnoxious personality.
>
> I have explained what is technically required for a signature as it is
> understood for Usenet messages and by properly working newsreader software,
> which is not met here.
Your problem is you don't comprehend what constitutes a "signature".
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb
Can you give URL's to what you have been reading lately?
> Can Thomas' claim be substantiated?
Yes. From your own URL in fact:
<quote cite="http://www.faqts.com/knowledge_base/view.phtml/aid/35742>
The version independent program id for an XML HTTP request object is
Microsoft.XMLHTTP
thus
var httpRequest = new ActiveXObject('Microsoft.XMLHTTP');
creates an XML HTTP request object in IE 5 or later.
Which actual MSXML version such a program id is bound to depends on the
MSXML version(s) installed and even on the mode (side-by-side or replace
mode) a version is installed in.
</quote>
Until I see something that proves Martin wrong, I believe what he writes
- unconditionally.
Randy Webb
new ActiveXObject("MSXML2.XMLHTTP");
Will use whatever the latest version the user has installed. If you
specify a version, then it will only support what that version had in it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - ttp://www.JavascriptToolbox.com/bestpractices/
Peter Michaux
> Peter Michaux said the following on 12/16/2007 7:49 PM:
>
> > On Dec 16, 7:47 am, VK <schools_r...@yahoo.com> wrote:
> >> On Dec 16, 4:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> >> wrote:
>
> >>> Not using Google's faulty Web interface, unless one temporarily has to,
> >>> might be the solution to this problem.
> >> Or using a descent NNTP server for posting: in my memory this is the
> >> first time ever in Google Groups the title is displayed but no body.
> >> Also my free two free NNTP servers I am using as a reserve one missed
> >> the post completely, other reported the same header w/o body. Someone
> >> is playing hard with message headers I guess (?)
>
> >> Anyway I have gotten the post over developersdex mirror:http://www.developersdex.com/asp/message.asp?p=2978&r=6080012
>
> > Thanks.
>
> > Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
> > XMLHTTP version installed on the client system." and I believe that
> > is not true based on things I've been reading lately.
>
> Can you give URL's to what you have been reading lately?
The only links I still have are the ones I posted
> > Can Thomas' claim be substantiated?
>
> Yes. From your own URL in fact:
>
> <quote cite="http://www.faqts.com/knowledge_base/view.phtml/aid/35742>
>
> The version independent program id for an XML HTTP request object is
> Microsoft.XMLHTTP
> thus
> var httpRequest = new ActiveXObject('Microsoft.XMLHTTP');
> creates an XML HTTP request object in IE 5 or later.
>
> Which actual MSXML version such a program id is bound to depends on the
> MSXML version(s) installed and even on the mode (side-by-side or replace
> mode) a version is installed in.
> </quote>
>
> Until I see something that proves Martin wrong, I believe what he writes
> - unconditionally.
<quote site="http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-
the-right-version-of-msxml-in-internet-explorer.aspx">
#
Version Independent ProgIDs - There's a lot of confusion around the
"version-independent" ProgID for MSXML. The version-independent
ProgID is always bound to MSXML 3 (a lot of people think it picks up
the latest MSXML that is on the box). This means the version
independent ProgID and the "3.0" ProgIDs will return the same object.
For example both statements in the following code will return an MSXML
3 DOMDocument:
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0')
and
var xmlDOM = new ActiveXObject('Msxml2.DOMDocument')
</quote>
Confusing, eh?
Randy Webb
I read that part as well. It is referring to two different things
though. DOMDocument versus XMLHTTP. Martin could come closer to telling
you the difference in the two than I can.
Peter Michaux
The DOMDocument part is just a "for example". I think the statement is
general and does apply here.
I know that Martin certainly knows his stuff but the XML blog does
seem to be making a different statement here.
Randy Webb
If you think that is confusing, try finding anything in MSDN to tell you
how to find out what version this code uses:
var xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');
How do you test to see what version of XMLHTTP it is using? I can tell
you this much, this didn't work:
var xmlhttp30 = new ActiveXObject('Msxml2.XMLHTTP.3.0');
var xmlhttp40 = new ActiveXObject('Msxml2.XMLHTTP.4.0');
var xmlhttp60 = new ActiveXObject('Msxml2.XMLHTTP.6.0');
var xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');
if(xmlhttp30 == xmlhttp){alert('It used 3.0')}
if(xmlhttp40 == xmlhttp){alert('It used 4.0')}
if(xmlhttp60 == xmlhttp){alert('It used 6.0')}
But then again, this didn't either:
var xmlhttp1 = new ActiveXObject('Msxml2.XMLHTTP');
var xmlhttp2 = new ActiveXObject('Msxml2.XMLHTTP');
if(xmlhttp1 == xmlhttp2){alert('Equal')}
Now I remember why I stopped mucking with ActiveX Objects. Too big a
pain in the ass.
> I know that Martin certainly knows his stuff but the XML blog does
> seem to be making a different statement here.
Given the current state of the quality of MS blog's and MSDN
documentation, and Martin's track record, I believe Martin. Would be
nice to see a test to see which one it uses though to make sure.
Martin Honnen
> Given the current state of the quality of MS blog's and MSDN
> documentation, and Martin's track record, I believe Martin. Would be
> nice to see a test to see which one it uses though to make sure.
Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
or earlier but not to later versions. The same holds for
Microsoft.XMLDOM and Microsoft.XMLHTTP.
So to create a DOMDocument or XMLHTTP for MSXML 4, 5, or 6 you need to
use version specific program ids meaning you need Msxml2.DOMDocument.4.0
respectively Msxml2.XMLHTTP.4.0 for MSXML 4, Msxml2.DOMDocument.5.0
respectively Msxml2.XMLHTTP.5.0 for MSXML 5, and Msxml2.DOMDocument.6.0
respectively Msxml2.XMLHTTP.6.0 for MSXML 6.
The XML team blog is based on supported MS OS versions, those have at
least IE 6 or 7 and that way MSXML 3 around meaning
Msxml2.DOMDocument.3.0 respectively Msxml2.XMLHTTP.3.0 can be assumed as
being around and are therefore suggested as the common base.
If you want to write code for IE 5 or 5.5 then you are in area the XML
team blog does not cover as those versions respectively OS with those
version are no longer supported by MS. For those browsers you might want
to resort to Msxml2.DOMDocument respectively Msxml2.XMLHTTP or even
Microsoft.XMLDOM respectively Microsoft.XMLHTTP.
--
Martin Honnen
http://JavaScript.FAQTs.com/
Dr J R Stockton
Sun, 16 Dec 2007 20:58:43, Randy Webb <HikksNo...@aol.com> posted:
>Thomas 'PointedEars' Lahn said the following on 12/16/2007 7:44 PM:
>> Dr J R Stockton wrote:
>>> Since you evidently do not yourself understand how a signature should be
>>> constructed, as you have repeatedly been told, you are once again
>>> demonstrating your truly obnoxious personality.
>> I have explained what is technically required for a signature as it
>>is
>> understood for Usenet messages and by properly working newsreader software,
>> which is not met here.
>
>Your problem is you don't comprehend what constitutes a "signature".
I don't think he can be that stupid. It is merely a manifestation of
his defective personality. He must have a syndrome akin to Tourette's,
but with a different manifestation.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Randy Webb
> Randy Webb wrote:
>
>> Given the current state of the quality of MS blog's and MSDN
>> documentation, and Martin's track record, I believe Martin. Would be
>> nice to see a test to see which one it uses though to make sure.
>
> Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
> or earlier but not to later versions. The same holds for
> Microsoft.XMLDOM and Microsoft.XMLHTTP.
>
> So to create a DOMDocument or XMLHTTP for MSXML 4, 5, or 6 you need to
> use version specific program ids meaning you need Msxml2.DOMDocument.4.0
> respectively Msxml2.XMLHTTP.4.0 for MSXML 4, Msxml2.DOMDocument.5.0
> respectively Msxml2.XMLHTTP.5.0 for MSXML 5, and Msxml2.DOMDocument.6.0
> respectively Msxml2.XMLHTTP.6.0 for MSXML 6.
Thank you Martin. Is there any property you can check that will tell you
which version that microsoft/Msxml2.XMLHTTP is bound to?
var xmlhttp = new ActiveX('Msxml2.XMLHTTP');
var xmlhttpVersion = xmlhttp.whatPropertyToUseHere;
Any way to know?
Peter Michaux
> Randy Webb wrote:
> > Given the current state of the quality of MS blog's and MSDN
> > documentation, and Martin's track record, I believe Martin. Would be
> > nice to see a test to see which one it uses though to make sure.
>
> Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
> or earlier but not to later versions. The same holds for
> Microsoft.XMLDOM and Microsoft.XMLHTTP.
This is just what I have been looking for. Thank you!
Do you have a link to a bit of Microsoft documentation that states the
above?
Thanks again.
Martin Honnen
>> Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
>> or earlier but not to later versions. The same holds for
>> Microsoft.XMLDOM and Microsoft.XMLHTTP.
> Do you have a link to a bit of Microsoft documentation that states the
> above?
See the MSXML SDK
<URL:http://msdn2.microsoft.com/en-us/library/ms757837.aspx>, it states
the following:
"MSXML version 3.0 was the last version of MSXML to support
version-independent GUIDs and ProgIDs. Starting with version 4.0, MSXML
is installed on your computer in side-by-side mode. This means that, for
example, installing MSXML 5.0 for Microsoft Office Applications does not
replace any previously installed version of the MSXML parser on your
computer. This is done to protect the quality of applications that are
currently using earlier versions of MSXML. Side-by-side mode also allows
you to decide which version of the parser to use in your code.
After you install MSXML 4.0 or later, applications that use
version-independent ProgIDs continue to run using the most recent
version of MSXML prior to version 4.0. Typically, for most current
Windows systems, this will be MSXML 3.0. To use version 4.0 or later,
however, applications must be written to use the appropriate
version-dependent class IDs (CLSIDs) and ProgIDs that reference the
appropriate DLL (Msxml4.dll, Msxml5.dll, and so on)."
Martin Honnen
> Thank you Martin. Is there any property you can check that will tell you
> which version that microsoft/Msxml2.XMLHTTP is bound to?
>
> var xmlhttp = new ActiveX('Msxml2.XMLHTTP');
> var xmlhttpVersion = xmlhttp.whatPropertyToUseHere;
>
> Any way to know?
There is no object property you can inspect. There are tools however to
check the current settings, see
<URL:http://support.microsoft.com/kb/278674/en-us>.
Peter Michaux
Thank you.
If a version-independent classid/progid is to be used then it seems
"Microsoft.XMLHTTP" is better than using "Msxml2.XMLHTTP" as the
former will work with earlier msxml dll files. A developer could
optionally add the "Msxml.XMLHTTP.6.0" as a first choice.
I suppose this comes down to the developer's feelings on testing
resources available. If the developer has limited resources and is ok
with using the newest dll up to 3.0 that is available on the machine
and not testing every possible combination of browsers/dlls then the
developer could use "Microsoft.XMLHTTP". If the developer only tests
with msxml3.dll and thinks the code should be tested in every
combination in which XHR instantiation will work then the developer
could use only "Msxml2.XMLHTTP.3.0". Using "Msxml2.XMLHTTP.6.0" would
add yet another combination to be tested.
I have frequently seen the following as part of Ajax libraries to be
tried in order
var msxml = [
'MSXML2.XMLHTTP.3.0',
'MSXML2.XMLHTTP',
'Microsoft.XMLHTTP'
];
and given this discussion it seems this is equivalent to just
var msxml = [
'Microsoft.XMLHTTP'
];
VK
> and given this discussion it seems this is equivalent to just
>
> var msxml = [
> 'Microsoft.XMLHTTP'
> ];
Bingo! It took 22 extra posts to come to what it was said in the very
first reply in this thread :-)
Again: just don't forget that is totally true only for ajaxoids (XHRs)
so for making new HTTP requests from the same page, grab the server
response and handle it manually.
For a real complex XML tasks the used version may be of a big
importance.
Randy Webb
> On Dec 18, 10:53 pm, Peter Michaux <petermich...@gmail.com> wrote:
>> and given this discussion it seems this is equivalent to just
>>
>> var msxml = [
>> 'Microsoft.XMLHTTP'
>> ];
>
> Bingo! It took 22 extra posts to come to what it was said in the very
> first reply in this thread :-)
Microsoft.XMLHTTP will *not* use the "latest version on the machine". It
uses the latest up to 3.0 and nothing later. I have 6.0 available on
this machine but Microsoft.XMLHTTP will not instantiate it. It will use
3.0 instead.
VK
> Microsoft.XMLHTTP will *not* use the "latest version on the machine". It
> uses the latest up to 3.0 and nothing later. I have 6.0 available on
> this machine but Microsoft.XMLHTTP will not instantiate it. It will use
> 3.0 instead.
Right, and never stated the opposite. Please read my very first post:
"Now coming back to the original question of XMLHTTP versioning. If
the ajaxoid is "standardly misused" as a hidden browser to get textual
data from the server then it is irrelevant what version to use: any
will go. In this case it is better to stick to the universal alias
"Microsoft.XMLHTTP", that covers anything from IE4 till now. If the
ajaxoid is really used for XML data handling then it may be important
to know what XMLHTTP version is available: or not important - it all
depends on what XML features and XPath commands are used."
and the post you are replying to: