>In order to get an array from COM you have to send it to COM. I have not done anything between C++ and VFP COM but I can send to COM an array of chars, fill it and use in client apps.

I'd strongly recommend using a member property rather than having a parameter passed in get filled, if for no other reason than VFP has a tendency to move things around in memory. If you return the result through a public property, VFPm can construct whatever it needs to, stick it in a string and make it available by loading the property with the string it constructs; the C++ application can then treat the public member as a BSTR, which would allow you to pass back structures containg binary values, including null characters without worrying about the standard CString operations stopping before the end of a structure because of an embedded null.

I try to avoid parameters, relying on properties that can be populated before invoking a method - it makes things easy if you find yourself having to pass the same value around as a parameter. It also simplifies deployment considerably; passing parameters by reference to an out-of-process server, especially a remote out-of-process server, may be unpredictable, and if you use the OLE interface, translation between data representations in different languages is handled neatly and automatically.

I also avoid passing things like handles as parameters; it makes assumptions about how the server is deployed that I find to be self-limiting. Certain types of references to system resources may only be valid in the context of the current process, which forces you to use an in-process server (.DLL) without the option of deploying as a part of an MTS package, and nearly all of them are only valid on the local machine.