Dear Mike:

Ignorance can only be cured by acquiring knowledge, which only happens when you are aware that you are ignorant. If you know everything you can't be taught anything else.

My Chapter 16 contains the following, is this the chapter you are referring to?

Thanks
Bruce Strom

Chapter 16: Adding OLE
You can extend the power of your Visual FoxPro applications by employing the strengths of other Automation-enabled applications or ActiveX controls. In the forms or General fields of your applications, you can include specific functionality or data such as text, sound, pictures, and video from other applications. You can view or manipulate this data visibly by using the application that created it. Or, you can manipulate the data invisibly and automatically by controlling the application with Automation.

Other applications can also tap into the power of Visual FoxPro through Automation. You can even create Automation servers (COM components) in Visual FoxPro that your applications or other applications can access locally and remotely.

This chapter discusses:

Designing an OLE Application
Adding OLE Objects to Your Applications
Using ActiveX Controls
Manipulating Objects with Automation
Subclassing Objects
Controlling Visual FoxPro from Other Applications
Creating Automation Servers
Using Remote Automation


>> Now I know I am showing my ignorance, but others will benefit from the
>> conversation. Often you cannot learn if you do not show your ignorance.
>
>And, at the risk of sounding like a very mean person, ignorance can be cured. :-)
>
>>So a DCOM object behaves like a stored procedure on a server.
>
>Umm, sort of...I guess; probably not the best analogy, though. It actually behaves just like a regular COM server, it's just running on a remote machine. AFAIK, that's the only practical difference. When you issue 'CreateObjectEx("MyServer.Foo", "ARemoteMachine")', a COM object is created just like it would normally using CreateObject(). The only difference is that it's running on the remote box, not the local box. I highly recommend that you read the latter parts of Chapter 16 in the Programmer's Guide before proceeding further; all of this is explained pretty well in that chapter.
>
>>Can a DCOM object be run on a standalone Win95 or Win98 workstation?
>
>Yup.
>
>>How about NT Workstation or Windows 2000?
>
>Yup.
>
>>Of course it can run standalone on an NT Server since it would likely be
>>running as a service.
>
>Nope. NT Services are an entire different matter. On an NT/Win2K Server, it runs just like it would on any other box. If it's an EXE, it runs in it's on process space. If a DLL, there's an EXE on the remote box that serves as a DLL host (DLLHOST.EXE, I believe), since a DLL can't run on it's own.
>
>>In a nutshell, what is the difference between DCOM, COM, and DLLs?
>
>DCOM runs COM servers on remote machines, COM doesn't. DLLs run within the process space of the COM client (or DLL host, in the case of DCOM), EXEs run in their own process space outside of the process space of the COM client. Given this, a flaky COM DLL can take down the client process, whereas an EXE won't since it's running outside the client process space. Have I mentioned that it would be a good idea to peruse chapter 16 of the Programmer's Guide? :-)