Vlad,

Thanks a ton!

>I would say that this works if you restart VFP after you've set the breakpoints and set VFP as the executable for debug session (go to Project/Settings, choose the Debug tab). The debug will not be triggered if VFP is already started.

The reason we need to get to the debugger from VFP is because there is something different calling from VFP than there is from VC. The other guy has done all of his testing calling it from VC and now that we are trying to use the COM from a real language *g* we are hitting some snags. I was using Attach To Process under Build/Start Debugger which needs to have VFP running already and it wasn't working. I'll try the other to see if it works better.

>Are you sure all references to your object are broken? If yes and VFP still doesn't free the dll... there's not much you can do.

There was only one instance and I set it to .null., even a CLEAR ALL doesn't release VFP's grip on the DLL.

>That's probably because the methods declare return values. In this case, languages as VB or VFP will return the declared return value (which is actually a special parameter in the idl declaration) instead of the hresult value.

I'll have to look into this some more, because the other guys code is returning error status codes from the method.

>>4) How can I declare the COM method to take a BSTR string argument by reference so it can be an OUT or INOUT parameter. Just declaring the argument as BSTR doesn't let the method alter a variable passed by reference from VFP.
>
>Input parameter:
>IDL: MyFunction([in]BSTR tstrAString)
>C++: MyFunction(BSTR tstrAString)
>
>Output parameter:
>IDL: MyFunction([out]BSTR* tstrAString)
>C++: MyFunction(BSTR* tstrAString)
>
>Return value parameter:
>IDL: MyFunction([out, retval]BSTR* tstrAString)
>C++: MyFunction(BSTR* tstrAString)

I tried BSTR * and get all kinds of complaints by the compiler, but it now looks like I had a difference between the idl and the cpp file.