>>It's not a misnomer, it's a different use of the word than you are used to. In languages that support interface inheritance it is possible to state "this class will inherit from IHuntingdog". Stating this announces via your typelib that your class will support the Point and Retreive methods, as well as all of the methods required by by the interfaces that IHuntingDog inherits from: IDog (Bark, SniffCrotch) and IFourleggedAnimal (Walk, Breathe, PoopOnCarpet). When you declare in VB that your class will support IHuntingDog, VB creates these shell methods for you, and you are responsible for filling them out.
>
>Ok - I'll buy the "inheritance" terminlogy as explained - question - is the typlib somehow referenced in the registry? If not - how does a Dim Dog1 as IDOG find the interface PEMs?
>

Typelibs are registered in the registry. Also, before you can declare that an object implements IDog, you have to add a reference to the hosting dll to the VB project.


>
>>VFP's inheritance is great, but it does nothing for COM interaction. See above.
>
>Yes - but my point is that this is a decision COM (MS) makes - not a logical flaw necessarily in VFP inheritance
>

No, there's no flaw. One subject has little to do with another.


>so - there are certain methods (interfaces) that are required (by specific name) to play in this arena?

Certain types of clients require that server objects implement certain interfaces. For example:
- an OLEDB Simple Provider has to implement the OLEDBSimpleProvider interface. -- An ActiveX grid can bind to an ADO recordset because the recordset supports the DataSource interface.
- A Shell Extension handler is required to implement IPersistFile and IShellExtInit.
- The XMLHttpRequest.send() method takes a string or any object that supports IStream

You could write in VB an object that performs the above tasks, because VB lets you declare supported interfaces. You could write all the relevent code in VFP, but your object wouldn't work because it doesn't officially support the right interfaces.

If you look around windows enough, you'll find that Win32 is built around COM, and COM is built around the trusted relationships made possible by interface inheritance.

>Can you elaborate on what IUnknown and IDispatch are/do?

IUnknown is the only interface that ALL COM objects must inherit from. It only has three methods: QueryInterface, AddRef and Release. AddRef and Release increment and decrement the reference counter, and QueryInterface allows discovery of function addresses.
IDispatch inherits from IUnknown and has 4 more methods that allow runtime discovery and object invocation.

I can't really do a detailed discussion of COM justice, and this is definitely outside the scope of this forum. There are piles of articles describing the inner working of COM in MSDN. Drill down to Platform SDK->Component Services-> COM and go from there.

>Where specifically can I find this tool? TIA

It installs with Visual Studio 6.0 Enterprise. It's in the start menu under VS->VS Enterprise Tools. I use it so much that I have a shortcut to it on my startbar. I don't know if it comes with the professional version of VS or not.