3 Replies Latest reply on Apr 20, 2007 4:46 AM by Stephen B. Sealy

    Dealing with aliases used in imported WinHelp

    Stephen B. Sealy
      I am preparing to convert a large WinHelp system to RoboHelp HTML. There are roughly 150 HLP files with corresponding HPJ projects. When I did some trial conversions, I discovered that many of the external (HLP-to-HLP) links in the WinHelp projects were created using aliases, which the RoboHelp HTML conversion treated the same as topic IDs -- as in the following example:

      <a href="g_prfile\s-gloss.chm::\22_79CF.htm">

      where 22_79CF was an alias in the target WinHelp project.

      I could deal with this, but for one problem: some of the aliases are not currently defined in the target projects. I found many by decompiling the HLP files, but some are still missing.

      Many writers, years ago, worked on the help system. My best guess is that the writers worked with mismatched copies of the HPJ projects, and the HPJ projects that held the missing aliases are long gone.

      Does my guesswork make sense? The compiled HLP files seem to work fine, which would mean that an alias could come and go without breaking the link.

      Also, am I missing a conversion option that would correctly interpret the aliases used in external links? (I'm using X5.0.2, but could upgrade to 6 if it would help.)
        • 1. Re: Dealing with aliases used in imported WinHelp
          Level 2

          An "alias" in WinHelp and HTMLHelp is a different thing. In WinHelp, aliases were used to link multiple IDs to a single topic. The alias was simply a second name for the same thing. In HTMLHelp, aliases are part of a two tiered system, designed to delineate the developer's tasks from the help author's. An alias file is the help author's links to the topic IDs.

          When I converted from WinHelp to HTMLHelp some years back, the loss of WinHelp aliases was the only glitch in the conversion. Oddly, it didn't lose them all. If I remember correctly, it was picking up only the first of a list of WinHelp aliases. I had to fix all the rest manually. Hopefully, the newer versions of RoboHelp do a better job.

          Hope this helps,

          • 2. Re: Dealing with aliases used in imported WinHelp
            Stephen B. Sealy Level 1

            I'll be dealing with more than 9000 external links, so I'd like to minimize the manual fixes. I can write a VBA procedure to fix the links in the RoboHelp HTML sources if I can find the missing WinHelp aliases or devise some other substitution logic.

            It's good to know that some aliases are converted. Thanks for that information.

            I'll post another reply when the problem is solved.

            • 3. Re: Dealing with aliases used in imported WinHelp
              Stephen B. Sealy Level 1
              I stayed with x5.0.2 and took the following approach to convert the 157 HLP files:

              1) Decompiled the HLP files using RoboHelp for Word.

              2) Created a uniform Excel spreadsheet based on the resulting projects' External Links reports.

              3) Generated VBA code based on the WinHelp projects' aliases. The VBA code will populate arrays for translating the aliases to file names in the external links.

              4) Imported the projects to RoboHelp HTML.

              5) Wrote VBA procedures to validate the aliases used in links against the converted file names and to list the invalid aliases.

              6) Investigated the invalid aliases and updated the array code to fill in the missing alias translations. For some, I could spot a pattern, but 200 of them required looking up the link in the spreadsheet and searching for the topic in the original HLP file.

              I now have a complete list of alias translations that I will use to repair the links after I decide how to combine the projects. (That's a separate issue. The WinHelp projects used a lot of external popups, which are not supported in HTML Help, so I'll need to combine the affected projects to preserve the popups.)

              I'll use VBA procedures to repair the HTML source files. I'm accustomed to doing that. But this is bad news for anyone who does not use VBA or some other scripting program to fix HTML source files.

              I won't mark this as the final answer -- in hopes that someone will come along with a better one.