>Erik,
>
>You could say the same about including a WIN32 API call, what if you wanted to do COM on a VMS or Unix platform.

COM, AFAIK, is a Windows only standard. You would get into trouble trying to run a COM object in either of these other platforms, because they don't have the system resources to do it (unless they have implemented some 3rd party bridge-type solution to replace OLEAUT32.dll and the host of other system resources required to use COM).

But this isn't even the issue: intimate knowledge of its environment, and unusual requirements made of the caller are two completely different things. The VFP API functions available through the LCK are different from Win32 API functions; the former call OS functions, the latter use functions defined in the caller . Most COM objects that we think about every day could be instanciated and used from any environment in Windows that knows how to use COM objects, and VFPCOM cannot, because it uses functions in API of the process that called it.

I should clarify my statement to that "what VFPCOM does goes against COM" standards to say that VFPCOM employs some non-standard tactics to get the job done. This doesn't mean it's not COM (hear that, JVP? :-))

This is not a criticism of VFPCOM- I only wanted to point out what was not immediately obvious to me: one could not build a COM server in VFP that does what VFPCOM does, you would have to do it in another language like C++.