>I'm just asking what COM you plan to use on a shrink wrapped application. I say, only ones that you develop and distribute with the app.

PFMJI, but COM simply means Component Object Model, there is only one COM, you can distribute asp.dll (the ASP runtime) or you can distribute joeCOM.dll (my thirdparty COM component) or any other COM Server. COM Servers are just .dlls(or out of process .exe's) or ActiveX controls, or whatever that implement the COM interface(s)

COM is part of the Window architecture, and was developed as an answer to limitations in the machine level dependency of C++ that breaks encapsulation (IOW, C++ objects know too much about each other at the machine code level) that caused problems with .dlls compiled in diffenet compiliers at different times. One of the nice effects of this decoupling was that the code could be language, process, and machine independent, because COM provides a true interface/implementation split.

This has nothing to do intrinsically with n-tier development, it just facilitates it.

In short, you use can use COM (and often do) anywhere you use an object--just create a COM object, and instantiate it. Just include the COM dll in your distribution, and instatiate its objects. This is what you do(more or less) any time you use an activeX control on a VFP form.

The reason why COM is mentioned at all on a VFP test is because we can *create* COM servers, for use in any application, desktop, distributed, web, otherwise VB only, etc. And because we can instantiate COM objects (VFP created or not) in our applications.

HTH,
Bill