Linking to topics

[David Webber]

I am trying to link to topics in and outside of CHM files in javascript with

location.href = Url;

I want to compute Url from the current location, thisUrl, obtained from

var thisUrl = location.href;

Can anyone help me clarify the syntax of thiUrl for various situations on
the local machine.

If I load a local HTML file into IE7 then I get thisUrl as

file:///C:/.../.../filename.htm

or schematically file:///<path-with-forward-slashes>

If I am looking at a .chm file in the help engine, then I get thisURL as

mk:@MSITStore:C:\...\...\chmfile.chm::/.../...filename.htm

or schematically

mk:@MSITStore:<chm-path-with-back-slashes>::<internal-path-with-forward-slashes>

and I understand I might get

ms-its:<chm-path-with-back-slashes>::<internal-path-with-forward-slashes>

I'm somewhat puzzled:

1. Why are there these two separate conventions for paths to topics in chm
files?
2. When I look at location.href can I rely on the consistent use of forward
and back slashes in the above way?

[I'm trying to manipulate these strings based on getting any of the three
possibilities.]

Dave

[Rob Cavicchio]

Post by David Webber
If I load a local HTML file into IE7 then I get thisUrl as
file:///C:/.../.../filename.htm

...

Post by David Webber
If I am looking at a .chm file in the help engine, then I get thisURL as

...

Post by David Webber
1. Why are there these two separate conventions for paths to topics in chm
files?

Well...if you think about it, they have to be different. Otherwise how would
the system be able to tell the difference between an HTML file that was just
sitting on the disk (uncompiled) vs. an HTML file that's inside a CHM file?

Post by David Webber
2. When I look at location.href can I rely on the consistent use of
forward and back slashes in the above way?

I wouldn't rely on it. Windows paths use backslashes and URLs use forward
slashes, thus there is inconsistency and probably will be for a very long
time to come. I think in most cases Windows now accepts a forward slash as a
substitute for a backslash, but internally I'm guessing it's still using
backslashes so that's what gets generated for local file paths.

It is not that difficult to write script that treats the two as equivalent
when parsing a string. Below is a function that replaces all occurrences of
one string with another, so you could normalize a URL to forward slashes by
using something like:

fStringSubReplace(thisUrl, "\\", "/")

Here's the function:


function fStringSubReplace( vString, vStringSub, vStringSubReplace )
{
var vPosition = 0;
while( vPosition <= vString.length )
{
if( vString.substring( vPosition, vPosition + vStringSub.length ) ==
vStringSub )
{
vString = vString.substring( 0, vPosition ) + vStringSubReplace +
vString.substring( vPosition + vStringSub.length, vString.length );
// POSITION OF NEXT CHARACTER TO CHECK DEPENDS ON LENGTH OF REPLACEMENT
STRING
// IF REPLACEMENT STRING IS "", THEN NEXT CHAR IS SAME POSITION AS
PREVIOUS
vPosition = vPosition + vStringSubReplace.length;
}
else
{
vPosition += 1;
}
}
return vString;
}


********************
Rob Cavicchio
***@mvps.org

[David Webber]

"Rob Cavicchio" <***@mvps.org> wrote in message news:***@TK2MSFTNGP02.phx.gbl...

Thanks for your comments Rob - very helpful as always.

Post by Rob Cavicchio

Post by David Webber
1. Why are there these two separate conventions for paths to topics in
chm files?

Well...if you think about it, they have to be different. Otherwise how
would the system be able to tell the difference between an HTML file that
was just sitting on the disk (uncompiled) vs. an HTML file that's inside a
CHM file?

Yes, I realise that about the file:/// convention for straight HTML vs the
different convention for inside chm files. I was (and am) puzzled about
the reasons for two conventions

mk:@MSITStore:...
ms-its:....

both for URLs inside CHM files.

Post by Rob Cavicchio

Post by David Webber
2. When I look at location.href can I rely on the consistent use of
forward and back slashes in the above way?

I wouldn't rely on it....
It is not that difficult to write script that treats the two as equivalent
when parsing a string. Below is a function that replaces all occurrences
of one string with another, so you could normalize a URL to forward
slashes by using something like:...

Thanks! Looks very useful!

No more questions below, but just by way of background to my reasons for all
of this (in case there's any interest):

Many years ago I used to supply help documentation in two forms:

1) The .chm help was connected to the program with contents, index, and lots
of context-sensitive entries from F1 and Shift+F1 in the program. It is
readable in contents order, but is primarily designed for "dipping into" to
look things up with lots of hypertext links and so on.

2) For those who like a step-by-step guide to using the program there was a
thick, bound, printed tutorial manual organised as a series of lessons
demanding no knowledge which was not acquired in a previous lesson.

Printing and binding (and postage) costs being what they are, the latter
eventually became a pdf file, which folk can print if they wish. It has
been like that for some years now.

My latest move is to make it a CHM file, with each lesson a separate
internal HTML document. It will still be for sequential reading rather
than with lots of hyperext jumps, and I'll encourage folk to print chapters
to work through if they wish.

But CHM will allow two things if it is read on the computer screen:

a) Links into the program's primary CHM help file (very much like the
context sensitive help in the program itself);
b) Where the tutorial says open tutorial file .... (a document file for the
program supplied as part of the tutorial), I can put a link to the document
which will cause the program to open it.

In order to make this work if the tutorial is viewed as a.CHM file or as raw
HTML I'm starting with

var thisUrl = location.href;

and getting the current directory.

First by stripping off any prefix of the form

file:///
or mk:@MSITStore:
or ms-its:

and then by stripping any stuff at the end of the form

filename.chm::.......................

to find the current directory. Then I can locate the file I want with a
known path relative to that.

But of course this involves being careful with backslashes and forward
slashes, and the result can end up with either. I now have it working, but
your suggestion/function will enable me to rationalise this a bit.

Dave

[Rob Cavicchio]

Post by David Webber
Yes, I realise that about the file:/// convention for straight HTML vs the
different convention for inside chm files. I was (and am) puzzled about
the reasons for two conventions
ms-its:....

Ah, sorry I misunderstood the question.

I can't remember the reason, but MS introduced "ms-its:" when IE 4 came out.
(Believe it or not, CHM files work with IE 3, with the older
"mk:@MSITStore:" protocol). I think the new protocol was supposed to make
things more flexible somehow, but considering how little they did with HTML
Help after that, the whole issue has become mostly a curiosity.

To this day, in most cases the URLs that I see resolve to "mk:@MSITStore:",
but in the past I have seen properties on a topic resolve to "ms-its:", so
when checking URLs from a script you might need to check both. There are
some circumstances in which you specifically do *not* want to use "ms-its:"
when you create your links. I'd have to dig for the details, but I remember
something about graphics and style sheets not showing up in either context
Help or merged Help sets when you reference them with "ms-its:".


********************
Rob Cavicchio
***@mvps.org