>>Correct. COM servers can only access VFP environment stuff through objects you might have passed it.
>>
>>Ask your self this question though: if your COM server were to rely on data open in the VFP environment, why is it a COM server at all? The purpose for COM is get cross-platform compatibility. If you are calling your COM srever from VFP, and the COM server was written in VFP to only work with a VFP client, why the heck is it a COM server and not just a class?
>>
>>You are not the first person to ask this question on this forum, but the fact that it is getting asked worries me that many people are miunderstanding the purpose of COM. We should not be building COM server for the sake of building COM servers. If your only client for your server is VFP an the source for the server was VFP, you shouldn't be leaving the VFP environment to do this work. There is no use using a the Windows mechanism for object brokering when the objects are internally native in the first place. Trying to do this just makes implementation awkward, and greatly degrades performance as far as object instanciation times.
>
>Erik,
>
>I am doing exactly what you are saying not to do. In my case, it is part of a migration plan to eventually move to multi-tier architecture. By putting the business objects in a DLL and running that on the client, it will be much easier to migrate to MTS/COM+ down the road, which is the direction we are heading.

The difference between a VFP class and a COM server is only with the keyword OLEPUBLIC. My point is, while your only client is VFP, use the class as a VFP class because as of yet, there is no need for a COM interface. When you later need to use the object from another client or inside MTS, compile it OLEPUBLIC then. No other code needs to change.

This is just my personal philosophy, and I guess ultimately the difference is trivial.