>>>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.
>

Yeah, I know this, that's why I was confused by your first statement- I was assumiing a VFP client, which does not store strings as unicode.


>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.
>

Yup.

>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.

Yup.

>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.

Gotcha.