>>and in returning XML from a COM call the text is converted into a Unicode string automatically.
>
>What do you mean? That when I call any object from VFP that returns XML, the resulting string is unicode? Then why can I read it in VFP at all? I think I am misunderstanding you- could you expand?

No - VFP doesn't know anything about UniCode. COM on the other hand doesn't know anything about ANSI. VFP does the conversions automatically.

COM doesn't work with ANSI - everything COM is double byte. VFP performs behind the scenes translations of it's internal ANSI strings into doublebyte and back. When you pass a string in its ANSI (256 charset) when it gets to the COM object it's in Double byte. VB, VBScript, ATL etc. all use double byte/Unicode strings and VFP must perform the conversion to talk to them.

When you create an XML string (or any string for that matter) in VB or VBScript and pass it to a VFP COM object the string comes in as DoubleByte and is then converted into ANSI by VFP. When VFP returns the string it's converted from ANSI to DoubleByte. It's all transparent from VFP - you never write the code for this, because the translation occurs in the COM calls.

This is why returning a binary string from VFP typically fails because the implicit DoubleByte conversion stops at the NULL. This is a design flaw by the receiving software (ASP mainly) because it doesn't use the right function to figure out the size of the string - that function looks at the NULL. sysStringLen() on the other hand returns the correct length and allows binary data. Web Connection uses that to allow straight COM result data to be processed without having to do a CREATEBINARY() in VFP.

Functions like STRCONVERT are only for internal use in VFP - for example if you need to somehow display content in Unicode format for say an API call.

>
>>If you have binary data it needs to be encoded (typically MIME/Base64 is used for that) and the resulting string is still safe to be passed over standard COM interfaces without BinaryWrite() or CreateBinary() in VFP.
>
>Right- after you encode it. Unless I am missing something, why go to all the trouble in this case of Base64 encoding just to be able to use XML to send a table, when you could just use CreateBinary(), and send a DBF file? It's not like the XML message will ever be able to be consumed by anything other than VFP (it is a VCX).

Well, that's a design decision that has to be made. I've argued many times that XML doesn't make sense if you're doing VFP to VFP with flat data. XML makes sense if other clients are involved or if you need to send complex data. XML also makes it nicer to pass consistent data structures. Sending a file may cause failure, but there's no standard way to pass back error information.

Additionally, it appears there's a bug in IIS 5 that causes some problems with content type lengths and binary content. Apparently there's a really weird bug between WinINet and IIS 5 that causes this - but it's yet another one of those things that support is not willing to pin themselves down on. Each team blames the other and nothing gets done...

I have problems with this consistently on the message board when downloading messages from Win2k. You get The connection with the server has been reset, but only occurs whtn the data from the server is sent with a content length and contains binary data.

+++ Rick ---