>>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.
>
IOW, you're stating that I can create a variant in VBA, pass it by reference, assign a VFP object reference to it in a VFP COM object, and it is resolved internally by Excel? This doesn't sound like it would work. If the dynamic object that got created were defined as OLEPUBLIC, then it'd be a COM object, and the reference passed would be resolved through the COM interface. A VFP object shouldn't move across the COM boundary, any more than an open datasession would. If what you're saying worked as described, then the entire VFP memory model would be opened to Excel; getting at the content of an object involves working through several layers of the NTI (the Name Table used internally by VFP to resolve the names of things within the VFP environment) which isn't done except through use of the Fox API. If you can show a sample of code, specifically the method of the COM server that returns a VFP object to Excel, I'd like to see it.
>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.
It shouldn't be a DCOM issue at all - the marshalling issues should immediately arise even on the same machine using a local out-of-process server. The VFP object is persisting beyond the scope of the method that creates it, and Excel is acting directly on a VFP internal object - in theory, you should be able to use the same mechanism to return a reference to _SCREEN or _VFP to the Excel VBA code and have Excel navigate the reference, including references to other objects inside VFP.
