This project has moved and is read-only. For the latest updates, please go here.

C++/CX partial class support

Topics: User Forum
Sep 10, 2013 at 9:47 AM

We are getting wrong documentation generated in the following scenario in C++/CX.

(The reason for the strange setup is to work around the inheritance limitations in public Windows Runtime classes, so bear with me. :))
  • We have 50+ concrete class types. Lets call them ConcreteFooA, ConcreteFooB etc.
  • We have a special header "Foo_Partial.h". This declares partial ref class FOO_NAME { etc..} with common implementation details.
  • Each concrete class header does #define FOO_NAME ConcreteFooA and then #include "Foo_Partial.h". After that, the normal class declaration comes.
It's a variation of the macro tricks from COM/ATL really, but we thought partial classes would be nicer to work with.

However, the documentation gets mixed up, and I'd just like to first as if there is any sort of support for partial classes yet in SHFB?
Sep 10, 2013 at 6:20 PM
I don't know about C++/CX specifically, but with C#, the compiler merges the documentation from all parts of the partial class, and the generated XML file does not show whether the class was defined in parts, so Sandcastle does not care.

The C++/CLI compiler has had bugs in how it generates XML documentation files. Perhaps there are related bugs in the C++/CX compiler. Mr. Woodruff wrote that he might write a plug-in with which you could map incorrect compiler-generated names to the correct ones. Such a feature could help you with C++/CX.
Sep 10, 2013 at 11:08 PM
More information about what you mean by "mixed up" is needed. I do know that the C++ compiler has problems with forward references and typically won't resolve them. The result of that is links to other members rendered as invalid non-clickable links. Looking in the generated XML comments file, you can identify those as they'll have the "!:" prefix rather than a valid prefix such as "T:", "M:", "P:", etc. The only workaround for that problem that I'm aware of is to fully qualify the links including the appropriate prefix.

The plug-in mentioned above would only be of help in cases where the compiler generates a member ID that differs from the one Sandcastle generates from the metadata.

If you can provide a small example that demonstrates the problem and information on what you are expecting to see, you can e-mail it to me and I'll take a look at it. Bear in mind that it's been a long time since I've done and C++ programming and nothing with the latest managed code stuff. My e-mail address is in the About box in the standalone GUI and in the footer of the pages in the help file.