The Managed C++ or C++/CLI syntax representation isn't accurate.

For example: /// <summary> /// Gets the type of the stored class. /// </summary> property Type^ TargetType { Type^ get(); }

Which will show in the documentation preview as: property TargetType[]{
get; }

Or: Int32 AddCmd(CIoDouble^ oCmdVal, String^ cmdName, Double dScale) { ... }

which displays as: public Int32 AddCmd( CIoDouble^^ oCmdVal, String^^ cmdName, Double^ dScale )

It looks like documentor doesn't yet have proper support for handling the hat operator and simply inserts one itself. Nor does ^ mean it can be used as an array, only * does in some situations. Documentor shouldn't alter the syntax as that would change the meaning of the declaration (in most cases).

I don't have experience with C++ with Managed extensions, so I don't know the behaviour in there.

I admit we (I) haven't focused much on C++ syntax previews, but it's definitely something that needs to be fixed. Since I'm not a C++ guy, it's sort of hard to come up with decent tests for the syntax preview using C++.

The other problem is that it's almost impossible to add unit tests for the syntax preview due to the hard dependency on DXCore structural parser objects, but I'm working on that. In the meantime, it's manual integration-style testing all the way.

This is a good one. We'll see what we can do.

Well, that code snippet was part of a C++ managed/unmanaged wrapper library (corporate). I'll be happy to give a hand on it, if desired.

Just a thought, but might it be possible to export that DXCore parser tree into the xml reflection tree that Sandcastle uses?

After posting a survey on this (http://www.advancedsurvey.com/ survey 68141) the small number of respondents noted that they don't use CR_Documentor with C++. To that end, since it increases complexity in the preview code, I may just remove C++ syntax preview altogether... unless someone wants to step up and write it.

(I don't develop in C++ so it'll be exceedingly hard for me to validate the effort.)

Removing it would tie in with the ProductRoadmap in that it would be easier to create a unified syntax generator if the current one(s) were less complex.

Marking this "Fixed," but it's really not "Fixed" so much as "functionality removed."

It didn't appear that many CR_Documentor users were making use of the plugin in a C++ environment, and with my own lack of experience in C++ I'm unable to ensure a correct user experience with respect to the syntax preview.

In the case of C++, users will now see a "[Language not supported for syntax preview]" message in the place where a syntax preview would normally be. The XML documentation will still display correctly - only the syntax preview was affected.