Merge Tips from George

From: George Farkas AT DRTAX.CA

Subject: Building a modular help system

To: WINHLP-L@ADMIN.HUMBERC.ON.CA

Building a modular help system:

I wrote to ask help on building a modular help system. I would like to thank everyone who helped and offered input, especially Wendy Lee, Robert Chandler, Michael Mueller-Hillebrand, Bill Swallow and Daniel Leigh. If I forgot some of you, my apologies.

This is a list of my hints and tips, which may help you.

1. Make sure that your computer has the latest version (4.73) of the following

HTML Help components:

HH.EXE (4.73)

HHA.DLL (4.73)

HHCTRL.OCX (4.73)

ITCC.DLL (4.72)

ITIRCL.DLL (4.72)

If you have to distribute the modular file system, make sure that the version of HHUPD that you are distibuting will copy these components over previous versions. Not having the correct files will make the system unreliable. Because I re-installed the current version of HHUPD, I thought the correct files were copied. They were not, and many computers (I thought of it as an NT problem, because I found it first on several NT machines). Unreliability in HHUPD is still a problem.

2. The master CHM should be bare but not empty. Any size to the file seems to impact the slaves (merged files), but an utterly empty master will not work.

3. Graphics and stylesheets should be in the same CHM as the HTML files referring to them. No amount of coaxing on my part let me install them all in a separate CHM or only on the master.

4. To prevent opening many instances of the help file, it is advisable to add "target="_top" when creating hyperlinks. (from Bill Swallow) This is not absolutekly necessary, but advisable.

5. All calls or links to HTML files in CHMs other than the CHM file from which you are making the link should use the syntax

<href="ms-its:chmfile.chm::/filename.htm">. Although you can use the syntax

<href="chmfile.chm::/filename.htm">, this is less reliable.

This can be a considerable task if your directory structure is not replicated in your CHM system. In that case, use a find and replace program like Robert Chandler's FAR to make all the changes. I use it in batch mode and recompile the help on a nightly basis to include all changes.

6. Make sure that all <ul> tags in the table of contents have a matching </ul> tag. If this is not so, Tables of contents that may appear to be well structured on their own will fail within a merged set.

7. Make sure that the hhc file referred to in your Windows definition is the master CHM's hhc. (from Steve Wexler's "Creating Modular HTMLHelp Systems"). This ensures that whenever the tripane window (kb) is opened, it is always the master that generates the table of contents and not the merged file's HHC.

Michael Mueller-Hillebrand claimed that he could do the same with multiple Windows definitions. I could not get it to work that way. I'm not sure that I know when secondary windows definitions take effect. Microsoft uses that system in their

CHMs.

8. All CHMs must be in the same directory.

I hope that this will help at least a few of you. I still have outstanding problems, but have managed to get this working well enough.

From: George Farkas <george(AT)DRTAX.CA>

Subject: Building a modular help system

To: WINHLP-L@ADMIN.HUMBERC.ON.CA

HI John,

When my master had about 500 html files in it, the merged files would not merge correctly. When I decreased the number (now it has about 7), it worked fine. I have discovered no good reason fo this and did not have the time to experiment too much. That why I only said "seems to impact". Similarly, an empty master did not work.

I put the other 490 or so into another merged file, and had no problems.

george