MSDN/SDK links go in new window

Aug 3, 2007 at 8:21 PM
I've noticed that when you include MSDN/SDK links, and in the output you click on one of these links it loads inside your current system. For MSDN links I know it looks nasty, because it has your TOC, then inside the topic area it has MSDN's TOC, then the actually topic. This leaves less viewable area for the actually MSDN topic. Maybe should make MSDN/SDK links launch in a new window with a target attribute on the <a> tags.

Just a thought, I don't know if you can control this, or if this is something the SandCastle framework controls.
Coordinator
Aug 3, 2007 at 8:38 PM
It's controlled via the Sandcastle ResolveReferenceLinks2 component. To modify it you'd have to create a new build component or modify an existing one to further modify the links to add a target="_blank" attribute to the MSDN URLs. It's on my To Do list to investigate but I haven't looked into it any further.

Eric
Oct 17, 2007 at 5:45 PM
This was unfortunately implemented in Sandcastle after all. Because of this, I won't be using Sandcastle, and therefore no other programs using Sandcastle (like SHFB). There was nothing wrong with MSDN/SDK links opening inside the html help window. This is the expected behavior in all documentations out there. Noone reading a documentation, either inside VS or in an html help window, is expecting a browser window appearing out of nowhere when clicking on an MSDN/SDK link. If you close MSDN's TOC once, MSDN remembers (obviously using cookies), so you won't get it again in the future. So that was merely a problem at all. I'm really sad! I hope they will at least add the possibility to choose if you want target="_blank" or target="_top" (as it should be), in the future.
Coordinator
Oct 17, 2007 at 7:50 PM
Don't complain here as nothing will change. Post your complaint in the MSDN Documentation forum where it will get seen by the developers. Just my opinion but dumping Sandcastle because of this minor issue is rather extreme. Ask for it to change and you'll probably get it.

Eric
Coordinator
Oct 19, 2007 at 2:26 AM
I mentioned this to Anand and it's been made configurable in the next release. From Anand:

Ok. I fixed this and should be available next week. It is configurable now as:

<component type="Microsoft.Ddue.Tools.ResolveReferenceLinksComponent2" assembly="%DXROOT%\ProductionTools\BuildComponents.dll"
linkTarget="_top">
<targets base="%DXROOT%\Data\Reflection" recurse="true" files="*.xml" type="msdn" />
<targets files=".\reflection.xml" type="local" />
</component>

The default target is: _blank. If they want something else, then it should be configurable as shown above.

Oct 24, 2007 at 8:13 PM
Thank you for your interest and immediate response. I also thank you for contacting Anand about this. The solution that has been proposed, is fine. I've already applied the following change to VS2005.config (could be applied to the rest of presentation styles):

<!-- resolve reference links -->
<component type="Microsoft.Ddue.Tools.ResolveReferenceLinksComponent2"
assembly="{@SandcastlePath}ProductionTools\BuildComponents.dll"
locale="{@Locale}"
linkTarget="_top">
<targets base="{@SandcastlePath}Data\Reflection" recurse="true" files="*.xml" type="{@SDKLinks}" />
<targets files="reflection.xml" type="{@ProjectLinks}" />
</component>

I hope my approach is correct. Now all I need is the new version of BuildComponents.dll that will support this. I presume that in future versions of SHFB, this could be configurable through the UI as well.
Coordinator
Oct 25, 2007 at 4:11 PM
The CTP refresh has been pushed back until next week. I'll see about making the link target configurable.

Eric
Coordinator
Oct 25, 2007 at 4:12 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.