Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Microsoft.XMLHTTP on Windows 8 Using VFP 9.0 1
- Thread starter Auguy
- Start date
- Thread starter
- #3
Olaf Doschke
Programmer
Thanks for checking and confirming, Ali.
If MSXML would not be part of Win8, many things wouldn't work. Therefore this was not to be expected to fail. More specifically especially since VFP9 is reported fully compatible, this includes XMLTOCURSOR, which roos in MSXML3 like Microsoft.XMLHTTP does.
in short start using:
Microsoft.XMLHTTP was the MSIE way of the XMLHttprequest for modern web Ajax technology, but meanwhile not only Chrome, Firefox, Safari, Opera etc., but also IE10 has this embedded in the browser itself and it's Javascript engine without depending on MSXML COM classes.
As you know Win8 introduces IE10 (which also works on Win7/Vista) and the WinRT tiles, which use the same browser stack as the IE10 browser, but not the final desktop UI layer, and allow no ActiveX plugins, as ActiveX requires the full blown support of Windows API, C++, VB or other runtimes, depending on the language, the ActiveX is developed with, and as Tiles work on any device type, they can't depend on the full windows and language runtimes, but on the limited set of WinRT. IE10 as the Win8 desktop browser still allows plugins, there are rumors it's ActiveX free, but it's not. It just prefers plugin free usage of native HTML5.
For more in depth info about that, see eg it tells about X-UA-Compatible: requiresActiveX=true header.
This also tells you how to handle activex based sites for IE10.
What is more of a concern is the availability of MSXML3. Then also VFP9 itself will suffer from it's XML Functions rooting there, XMLTOCURSOR mainly, XMLAdapter and some other XML classes root in MSXML4, which will live longer. Well, the benefit from XMLToCursor is limited anyway.
In regard of http requests you still have plenty of possibilities, if you want to stay with your code longer than MSXML3 lives, stop using the version independant COM class name Microsoft.XMLHTTP, which will only use MSXML3, but start using MSXML2.XMLHTTP.6.0 and only if that fails fall back to MSXML2.XMLHTTP.3.0 (or Microsoft.XMLHTTP), like suggested here:
For more info about the MSXML versions (and why 4 and 5 don't play a major role)
see MSXML3 is at SP10 already, MSXML4 at sp3, both still have their roadmap parallel to MSXML6, the most modern version, and 5 (for Office)
For another recommendation of MSXML6 for the XMLDocument
see
One caution: If you start using MSXML6, your code will continue to work, I can't confirm in all details, but surely for the main purposes of GET/POST/HEAD etc requests and in regard to XPATH and the XMLDOM object the cmopatibility is given and as far as I read MSXML6 is fully compatible. But of course MSXML6 offers more and if you start using that the fallback to MSXML3 for older OS won't work. The good news is MSXML6 is also part of XP SP3, so there should be no problem, unless your user go back to Win2k, Me or even 98.
Bye, Olaf.
If MSXML would not be part of Win8, many things wouldn't work. Therefore this was not to be expected to fail. More specifically especially since VFP9 is reported fully compatible, this includes XMLTOCURSOR, which roos in MSXML3 like Microsoft.XMLHTTP does.
in short start using:
Code:
Try
oXMLHttpRequest = CreateObject("MSXML2.XMLHTTP.6.0")
Catch
oXMLHttpRequest = CreateObject("MSXML2.XMLHTTP.3.0")
EndtryMicrosoft.XMLHTTP was the MSIE way of the XMLHttprequest for modern web Ajax technology, but meanwhile not only Chrome, Firefox, Safari, Opera etc., but also IE10 has this embedded in the browser itself and it's Javascript engine without depending on MSXML COM classes.
As you know Win8 introduces IE10 (which also works on Win7/Vista) and the WinRT tiles, which use the same browser stack as the IE10 browser, but not the final desktop UI layer, and allow no ActiveX plugins, as ActiveX requires the full blown support of Windows API, C++, VB or other runtimes, depending on the language, the ActiveX is developed with, and as Tiles work on any device type, they can't depend on the full windows and language runtimes, but on the limited set of WinRT. IE10 as the Win8 desktop browser still allows plugins, there are rumors it's ActiveX free, but it's not. It just prefers plugin free usage of native HTML5.
For more in depth info about that, see eg it tells about X-UA-Compatible: requiresActiveX=true header.
This also tells you how to handle activex based sites for IE10.
What is more of a concern is the availability of MSXML3. Then also VFP9 itself will suffer from it's XML Functions rooting there, XMLTOCURSOR mainly, XMLAdapter and some other XML classes root in MSXML4, which will live longer. Well, the benefit from XMLToCursor is limited anyway.
In regard of http requests you still have plenty of possibilities, if you want to stay with your code longer than MSXML3 lives, stop using the version independant COM class name Microsoft.XMLHTTP, which will only use MSXML3, but start using MSXML2.XMLHTTP.6.0 and only if that fails fall back to MSXML2.XMLHTTP.3.0 (or Microsoft.XMLHTTP), like suggested here:
For more info about the MSXML versions (and why 4 and 5 don't play a major role)
see MSXML3 is at SP10 already, MSXML4 at sp3, both still have their roadmap parallel to MSXML6, the most modern version, and 5 (for Office)
For another recommendation of MSXML6 for the XMLDocument
see
One caution: If you start using MSXML6, your code will continue to work, I can't confirm in all details, but surely for the main purposes of GET/POST/HEAD etc requests and in regard to XPATH and the XMLDOM object the cmopatibility is given and as far as I read MSXML6 is fully compatible. But of course MSXML6 offers more and if you start using that the fallback to MSXML3 for older OS won't work. The good news is MSXML6 is also part of XP SP3, so there should be no problem, unless your user go back to Win2k, Me or even 98.
Bye, Olaf.
- Thread starter
- #5
Olaf Doschke
Programmer
Just one more thing to add:
Indeed the javascript implementation of IE7 introduced the XMLHttpRequest class already and since then you wouldn't need to use ActiveXObject("MSXML2.XMLHTTP.3.0").
What I don't find anymore is a reference saying, when and if the IE javascript XMLHttpRequest class was decoupled from MSXML, maybe it was never, only was decoupled from the COM interface to msxml. It wouldn''t make sense to have two xml implementations.
Bye, Olaf.
Indeed the javascript implementation of IE7 introduced the XMLHttpRequest class already and since then you wouldn't need to use ActiveXObject("MSXML2.XMLHTTP.3.0").
What I don't find anymore is a reference saying, when and if the IE javascript XMLHttpRequest class was decoupled from MSXML, maybe it was never, only was decoupled from the COM interface to msxml. It wouldn''t make sense to have two xml implementations.
Bye, Olaf.
- Thread starter
- #7
-
1
- #8
Olaf Doschke
Programmer
No issues with 64bit, as there always is a 32bit subsystem.
The OS can make use of more than 4GB RAM, you get 2GB mostly, but that's fine. You don't notice much differences, unless you enforce installing some FLL, DLL, driver to system32. This is redirected to the 32bit SYSWOW64 subfolder in the normal case. That's where you find regsvr32.exe and other system tools in 32bit versions. But if you start regsvr32 from a 32 bit process you start the 32bit version anyway.
The main problem is MS Common Controls are missing from the OS, but that's because it's XP or newer, and the MS common ActiveX controls are not preinstalled, if you don't have the luck your customers also install an older Office. These controls are not part of Windows anymore. But that's not a 64 bit problem, but a problem of ActiveX being outdated.
Bye, Olaf.
The OS can make use of more than 4GB RAM, you get 2GB mostly, but that's fine. You don't notice much differences, unless you enforce installing some FLL, DLL, driver to system32. This is redirected to the 32bit SYSWOW64 subfolder in the normal case. That's where you find regsvr32.exe and other system tools in 32bit versions. But if you start regsvr32 from a 32 bit process you start the 32bit version anyway.
The main problem is MS Common Controls are missing from the OS, but that's because it's XP or newer, and the MS common ActiveX controls are not preinstalled, if you don't have the luck your customers also install an older Office. These controls are not part of Windows anymore. But that's not a 64 bit problem, but a problem of ActiveX being outdated.
Bye, Olaf.
- Thread starter
- #9
- Status
