I have a COM documentation project. When I generate my CHM file, each method and property has two topics:
XXX Property and XXX Implemented Property
XXX Method and XXX Implemented Method
How can I just generate one topic for each these - I only want XXX Property and XXX Method (not XXX Implemented Property and XXX Implemented Method in addition).
An Implemented Method / Implemented Property topic will only be generated for methods / properties on additional interfaces implemented by a coclass. Methods / Properties on the default interface will be documented as just regular Method / Property topics.
If you are seeing some different behavior to this, could you send a copy of your COM component / type library to support@innovasys.com so that we can investigate further.
All the coclasses have a default interface of IUnknown. This means that all my usable interfaces are considered "additional interfaces" and therefore generate Implemented Method / Implemented Property topics in addition to the Method and Property topics.
Is there some way to suppress this and not get the Implemented Method / Implemented Property additional topics?
Only by correctly marking the default interface. It sounds like you know what the default interface is, but it isn't marked as such in the type library?
It's pretty uncommon not to have a default interface - without it your classes will not support the object browser / intellisense in Visual Basic and other development environments.
The default interface is correctly defined as IUnknown for my coclasses. My classes all support the object browser and intellisense in the Visual Basic 6 and Visual Studio 2005 development environments. I can QueryInterface for other interfaces on my coclasses in VB and C++ correctly. So, my coclasses and interfaces are defined correctly in the COM component. BTW, my COM component is implemented as an ATL C++ project. In ATL projects, the IUnknown interface is generally given the [default] attribute -- this is because VB hides the default interface on a class, and the IUnknown interface is not required by VB developers.
Even if there was a different default interface, that wouldn't solve the problem I'm having, since some of my coclasses have several interfaces and I don't want to have the additional Implemented Property / Implemented Method topics for any of them. I just want the Property / Method topics for all my interfaces.
Thanks for the further information. In our experience it's typical to define a specific default IDispatch derived interface on ATL coclasses - it is that interface (and only that default IDispatch derived interface) that VB displays in the object browser.
The objective in the Document! X output for ActiveX is to make the member list match what you would see in the VB6 / other object browser. Could you send me (richard@innovasys.com) a copy of your type library so I can ensure that I am understanding the issue, and to ensure that there isn't some bug in the way Document! X handles additional interfaces.
You could customize the standard template to change the terminology used for implemented methods / properties, but Document! X would still see them as a distinct set separate from the default interface I'm afraid.
Thanks Richard - I emailed you my type library directly. Something else I realized is that the generated topics for my interfaces as well as classes are using the term "object" instead of "interface" or "class". So, the classes as well as the interfaces use "object.".
For example, I have:
Class1 Object
IClass1 Object
IClass1AnotherInterface Object
I expect to see:
Class1 Class
IClass1 Interface
IClass1AnotherInterface Interface
Thanks for sending your type library. I have confirmed that your coclasses all show zero members in the VB6 object browser as the default interface is set to IUnknown. If your default interface on these coclasses was set to the appropriate interface (e.g. IArcPadExchange on the ArcPadExchange coclass) the VB6 object browser (and others) would show the correct member list, and Document! X would produce documentation to reflect this.
At present, Document! X is documenting exactly what is there - zero members on the default interface and your Interfaces as Additional Interfaces.
You can mark your interface modules as interfaces in the Content File - select the module in the Content File tree and tick the 'Is an Interface' flag.
Thanks for the tip on checking the "Is an Interface" check box - that helps with my layout.
Regarding the other issue - the VB Object Browser is limited in that it only shows the default interface for a coclass under that coclass (and it hides IUnknown).
It's a perfectly valid COM design to specify IUnknown as the default interface as well as have multiple interfaces for a particular coclass.
Unfortunately, the VB Object Browser is a bit simplistic and doesn't reflect that.
A better object browser, like OLE View, displays the relationships correctly.
I don't understand why Document! X 5 follows the VB Object Browser's simplistic display of the COM library rather than the actual correct relationships in the COM library. Although I have a valid COM design for my library, Document X! 5 leaves me with two entries for every property and method.
So my index has:
XXX Implemented Method
XXX Method
YYY Implemented Method
YYY Method
ZZZ Implemented Property
ZZZ Property
This is going to be confusing for the end users of this help system.
I really need to have one or the other.
I didn't mean to suggest that it wasn't a valid COM design to specify IUknown as your coclasses default interface - it's just not typical in our experience. Doing this means that you cannot create an instance of your coclasses in VB (or .NET with the standard interop wrapper) and use them without casting to a specific interface. I'm guessing that you wouldn't be able to use them from scripting languages either - these appear to be pretty good reasons for marking specific dispatch interfaces as default, and this appears to be most common practice in general consumption COM components. I don't recall a single commercial component, or one bundled with Visual Studio or the various MS SDKs, that does not follow this design pattern.
It's not really a question of copying the VB6 object browser - it's a case of trying to accurately represent in the documentation which members are considered to be members of a coclass, and what are actually members of an additional interface implemented by that coclass. Each additional interface could have a member with the same name - hence including all members in a single list is logically not possible and that's why the default interface is so important in that respect.
Hope that makes things clearer on the reasoning for how Document! X handles COM components.