>Hmm good question. Prior to your posting, I had only tested with a VFP client calling the COM object, and it works like a charm.

Hmm, now I'm confused. The code you posted creates and calls a native VFP object as the COM wrapper, so it makes sense that VFP should have no problem with it. When I modified the wrapper code to delegate to the "aggregated" COM object, I get "unknown name" errors.

>But I just tested from VB, and on the PEMs that aren't defined in the typelib, it chokes with "Property not defined".

If the interfaces aren't defined in a typelib of some sort (either in the DLL or a seperate TLB), how else is a client supposed to see them?

> I guess this is kind of telling about the difference in how VB and VFP call COM objects.

At the core of it, there's only a couple of ways, CoCreateInstance and CoGetClassObject, both of which are going to require some kind of typelib info. (Of course, there's also #import, but VB and VFP aren't going to use those, and it still requires a typelib.)

Like I said, I'm a little confused and I assume I must be missing something. Could you clarify on how this wrapper object is to be visible from a COM client?

Thanks,