This article provides a binary fix and explanations about a rather irritating MSDN 7 scrolling bug.
The bug is : when you return from a page, the scroll position is lost, which means browsing content back and forth is very hard.
In our example, the What's New in Visual Studio .NET page is reopen with the scroll position at top instead of bottom.
The zip package has 4 files. 2 files are associated to each MSDN 7 toplevel topic. Default MSDN 7 toplevel topics are : MSDN library and .NET framework SDK.
Those files are the fixed compiled html help files, namely commoner.hxs
, and commoner.hxi
.
The help files for the MSDN library topic reside in this folder : <vc7installdir>\Msdn\1033
.
commoner.hxs
and commoner.hxi
files.
commoner.hxs
and commoner.hxi
Update progression : the MSDN7 help system does a touch on files when it is started, and it figures out that 2 new files have been introduced. A waiting box is displayed while indexes are updated :
The help files for the .NET framework SDK topic reside in this folder : <vc7installdir>\FrameworkSDK\Docs
.
commoner.hxs
and commoner.hxi
files.
commoner.hxs
and commoner.hxi
The scrolling bug is due to a weird javascript use somewhere in the plethore of internal javascript files executed with each page display and each page click.
MSDN 7 uses the new MS HELP 2.0 Workshop (whose SDK is available here[^]). Underlying things are somewhat harder to handle since not only the files are compiled, but MS introduces a new ms-help protocol.
What I did was scan the Internet Explorer cache while I was browsing the MSDN7 doc. Doing so, all internal files started to appear in the temporary internet files folder (since Internet Explorer does not directly execute hxs compiled stuff). Taking all the stuff offline, base-hrefed, I could fix the bug in one of the javascript files, namely dtue_ie5.js
(which unlike the name suggests is also used with Internet Explorer 6).
The bug is MS guys do a nasty document.body.scroll = no
in the resizeban()
function implementation.
But, with that in hands, I was pretty much going nowhere since it was impossible to put back the fixed javascript file as part of the MSDN7 workflow (in fact, there is one way to do so if you spoof the user-agent string, and make your Internet Explorer version look much older).
I had to download the MS HTML HELP 2.0 Workshop SDK, and use the hxcomp.exe back and forth to decompile the existing .hxs file (from VS.NET release 1.0), in order to get the internal tree of files, fix it, and compile it back, updating the .hxi index file as well.
Stéphane Rodriguez - Nov 28, 2002.