>
>An out-of-process server can have a UI, however, it is not an ActiveX control; it doesn't participate in the Windows Event loop for a client application, but has its own, completely independent UI. This can be a really, really bad thing if you deploy an out-of-process server remotely, since the client could never reach the server's UI.
>

So, as I feared, perhaps I was the only one who had the mistaken impression that it was impossible to make a visible COM component with VFP <s>. I've just never seen anything written about it nor heard of anyone doing it.

What you are saying about this being limited to EXE servers that must be registered on the client makes perfect sense. So I could't use the visual component in a web server app or DCOM situation because the user would never see it on the client machine. [Although I could still use the component if indeed the visual part of it is not what I want to them to work with anyway - several examples from Rick Strahl and others show this.]

We recently did a "data importing wizard" app for a client who calls the wizard from their C++ application. Thinking that they'd never be able to see our UI, even if registered as a COM component on the client machine, we distributed it as a "typical" VFP standalone EXE that the client merely runs from within their C++ application. Our method of communication is to create a disconnected ADO recordset from the imported data that the C++ app then picks up and works with.

Knowing now that we could have done this as a COM component, it sounds as if we should have been able to merely create the ADO recordset and pass it back to the C++ application - saving the time for VFP to disconnect (.Save()) the recordset and the time for C++ to re-connect (.Open()) it. From what I've described, does that sound correct (disregarding the fact that the standalone EXE has the advantage - in the client's opinion - of being able to have all clients run one copy off the LAN server)?

Kelly