>I like the decisiveness of your response. Thanks for the input. What I'm trying to figure out is how one knows whether such an object is the SELF-registering type. Does that make any sense? I'm using InstallShield to distribute an application of mine and you have to say whether a DLL or OCX you're installing is self-registering or not, and shared or not.
>
>(Maybe I should call InstallShield but wanted to make sure I knew what I was talking about.)
>

A self-registering .DLL is a .DLL that implements standard entry points for registration, and then writes some information about itself into the Windows registry when it's given a chance to do so. The easiest way to find out if something has self-registration code is to run REGSVR32 against it; if REGSVR32 doesn't blow up (something like the DLL was loaded but the DLLRegisterServer entrypoint was not found), telling you that it can't find an entrypoint in the .DLL to trigger self-registration, it's not OLE-enabled, and therefore not self-registering. In general, the documentation from a vendor will tell you if something needs registration, for example, if you examine the VFP6R.DEP file, it tells you which of the components require registration there.

Welcome to the world of rolling your own installs...you're going to find that you need to understand a good deal about the components that you use and their dependencies to make an isntallation work right. Just wait until you discover that registration of one component may require that another be registered first because the second depends on functions or registry data from the first .DLL!