Prototype style, langword and language filter

Aug 18, 2011 at 11:23 AM

Hi,

when you use the <see langword="..."/> tag and then build the documentation using the prototype style, it generates spans with different classes (vb, cs and so on) that are hidden/displayed when you change the language with the combobox in the upper right corner (as expected). This also changes the language of code samples on the page. However, this doesn't work the other way round: if you change the language of a code sample, it doesn't change the selected language in the combobox and replace the spans. Is this by design or is it a bug? Also, is there an (easy) way to create the behaviour I described?

Regards,
Daniel

Coordinator
Aug 18, 2011 at 7:22 PM

Most likely it's just the way it works.  It's been a long time since I've used the Prototype style so I don't recall the behavior much.  It's deprecated now along with the Hana style due to lack of support for MS Help Viewer output.  The VS2005 style is the only one that's been updated consistently with each new release of Sandcastle.

Eric

 

Aug 20, 2011 at 5:00 PM

Eric,

We've noticed that our documentation is much, much slower to build when using the VS2005 style as opposed to using the Prototype style (with Sandcastle Help File Builder v1.9.3.0). The difference is significant: 8 minutes per package with Prototype vs. 40 minutes per package with VS2005.

Besides the fresher looks, this is the main reason why we've decided to use Prototype instead of VS2005. Now, since you're saying Prototype is deprecated - are there any plans to speed up VS2005, get another supported fast style replacing Prototype, or anythig of that sort?

Thanks,
Fabian

Coordinator
Aug 20, 2011 at 8:15 PM

Are you building multiple help file formats at once?  If so, that could explain it though I'd expect to see a similar slow down regardless of the presentation style.  The help formats are built independently of each other now due to changes required to support MS Help Viewer.  As such, if you build two or more help formats in a project, it will load multiple copies of several of the build components which can increase memory requirements.  If you aren't using the cached build components, it could slow it down as each would have to connect to the MSDN web service to resolve links.  Adding the cached build components to the project should help with that after the first build if that is the case.  I plan on looking into sharing the components across formats in a future release to help with these issues.

Eric

 

Aug 22, 2011 at 11:48 AM

No, that's not it: We're only building a single format (CHM/HtmlHelp1), and the caching components (Cached Framework Comments Index Data, Cached MSDN URL References, Cached Reflection Index Data) are enabled for both styles.

I've created two repro samples: a small one and a larger one. The speed difference caused by the styles isn't as big as in our actual build, but it can already be observed.

Small one (https://www.re-motion.org/download/SHFB_Spikes/SHFB_Spike_Short.zip): Prototype: 01:11; vs2005: 01:24 (118%)
Larger one (https://www.re-motion.org/download/SHFB_Spikes/SHFB_Spike_Long.zip): Prototype: 02:47; vs2005: 04:38 (167%)

Since the difference in build times grows with the package size and since we have some very large doc packages, the difference gets really significant. I've also noticed that the CHM files produced by the VS2005 style are about 60% larger (in the repro samples), so maybe this is related to the performance difference?

Regards,
Fabian

Sep 7, 2011 at 10:00 AM

I've removed the spikes from our web server. Contact me if anyone's still interested.