>>Ed,
>>Is this an interface limitation of DCOM or all COM?
>>
>
>AFAIK, it's COM; without the VFP engine, there's no visibility of the internal VFP representation.
>

Maybe that's the reason it works. The VFP runtimes are installed on the machines in question to allow the VFP COM server to run.


>>The reason I ask is because I have an Excel application that creates an instance of a VFP COM server. It calls a method of that server and that server returns an object with an array property. The Excel application receives the VFP custom object with no problems and the array is usable by Excel.
>>
>

>Does the Excel invocation of the method receive the object back, or does it access a parameter it passed in or a COM property to get the array? Excel can't create or use a VFP object on its own (it can instance a COM object that was written in VFP, but can't create or traverse a VFP native class instance on its own.) I don't see how Excel could directly access the content of the VFP object without a COM interface on it.

In Excel, I create an instance of a VFP COM server using createobject(). I DIM a variable as an Object and set it to the return value of one of my VFP functions. The function returns a dynamic object created using createobject("custom"). The VFP object adds a couple of properties (1 array, 1 non-array) using AddProperty and all this is visible to the Excel program.

As I said, this is done using the same machine so I'm wondering if the VFP runtimes were not present, if the results would be different. In this example, using DCOM to run a VFP COM server on another machine using the class ID (and not the Prog ID) wouldn't require the runtimes to be present.