Rick,

Thanks.

>Yes. Just set the startup program to VFP.EXE and build your VC code with debug settings, then run the project. It'll start VFP and stop on your breakpoints.

I got this working from Vlad's message this morning, it's very cool to be able to set method breakpoints. In 15 minutes I was able to isolate the problem to another back end the COM server is talking to not understanding the BSTR that was coming at it. I hacked the memory and converted the unicode BSTR back to ascii text, continued the method and it came back ok from the backend. It would have taken a couple of hours to track down without the VC debugger.

>You'll have to exit VFP. Again the scenario above does the trick.

With the added headache of not having a persistent VFP session with it's command window history there. There's also the problem that while in the VC method code VFP doesn't get paint messages so it's screen blanks out and you can't refer to the VFP memvars or trace window. I might try using the VFP debugger in it's own frame to see if that helps.

>Does the object support IDispatch? Otherwise VFP can't call these or it will get invalid values back.

It's a dual interface,

>Every IDispatch method must return an HRESULT. Return values are passed
>back via OUT (MIDL) parameters in COM objects.

I looked up retval on MSDN and got the return value out of the method.

>You need to set it up as a pointer to a BSTR (double reference) and then mark it as [IN,OUT].

I didn't get it changed in all three places (.cpp, .h and .idl). Once I did it worked great.