>>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.

AAAAAAAAAAAAaaaaaaaaaaaaaaaarrrrggggghhhhhh! I swear this worked two hours ago!!!!

I just tested again, and get the same errors you get. I must have fudged my test earlier, and confused myself.

>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?

Mike, you make too much sense. I was sort of surprised the first time I tested and it worked, but I should have been more suspicious of the results, because this is the exact hurdle that causes AddPropertyed properties to fail. Duhh.

>> 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.)

Yeah, I had a slim hope that I would be able to fill the VFP compiler into including the DOM object in the TypeLib By putting a IMPLEMENTS IDomDocument....

But VFP does a precompile check for all of the required elements before allowing you to compile, and since I didn't really want to implement them, the compile failed.


For those watching on- sorry to mislead you, but the technique is still really cool for creating a native fox subclass of a COM object...