> Another way is the addref the type library when the ITypeInfo wherever a > ITypeInfo interface is initially created (like in GetTypeInfoOfGuid) but I > think this is more dangerous, since then you have to have some way for this > refcount to go away, and ITypeInfo_Release() doesn't know who created it, > just that it was created. If you are careful enough to always put an addref > on the library when you create a new ITypeInfo pointer (GetTypeInfoOfGuid, > GetTypeInfo, IDispatch::GetTypeInfo, etc.) but this seems like a unwieldy > task to guarantee that the code is right in all of these places. It's much > easier to make the ITypeInfo_AddRef() and ITypeInfo_Release() call > ITypeLib_AddRef() and ITypeLib_Release() on the containing ITypeLib > implementation when appropriate.
Yes, this is true. I hadn't considered that, it would be better to put the TypeLib addref in the TypeInfo addref. This feels a bit odd though, it would lead to the TypeLib having a reference count that was "too high" (though I suppose it doesn't really matter) if the receiver did their own AddRef on the TypeInfo, as the refs would propogate up. Still, the actual value of the refcount doesn't matter. > As far as C++ stuff vs. C stuff, in essence the pointer to the data > structure (including the VMT) is simply a C++ style class without the C++, > and with some special requirements... You can just replace my p->method() > with OBJECT_method(p) if you like to make it look like what I've seen from > wine. I'm still pretty new to the wine source, so it may not be like this > everywhere, I just don't have the time to look. True, what I meant was that there is no object constructor, unless you count the code where the struct is allocated and appended to the end of the linked list. thanks -mike -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
