updated October 7, 2001
Quite a few of the questions in this FAQ were taken from discussions on the WinHlp-L mailing list. The answers are from some of the most influential individuals in the Help community, including Ralph Walden, HTML Help Development Lead for Microsoft until his retirement in March of 1998.
Also, be sure to check the Microsoft HTML Help FAQ.
HTML Help Workshop is freely available for download from Microsoft. Everything necessary for the creation of HTML Help files is included ... an HTML editor, the compiler itself, tools for creating the navigation windows, etc.
A: The pages you're seeing here were done in Microsoft FrontPage 98. However, Microsoft recommends that developers use the raw HTML editor in the HTML Help Workshop itself. So far, I haven't seen any problems with using FrontPage for this purpose, but if I do, I'll take notes and publish them.
Q: I'm using HTML Help Workshop 1.1 to create a master Help file with a number of subordinate files merged in. Is there's a practical limit?A: Looking at the Visual Studio 6.0 HTML Help file, there's a master index file (over 90M in size) that calls the files for all of the packages. In the Visual Basic 6.0 batch, there are 67 of them at this writing, meaning the total is likely over 300. The limit is probably far beyond that number.
Q: I have created a merged CHM using RoboHTML 1.0 and HTML Help Workshop 1.1 that works fine when I run it on my network drive. When I put it on the Web server for our intranet (trying to simulate what users eventually will see when running it from our internet site) and run the master CHM from there (by launching IE 4 and entering the CHM http: path info at the address line), I get a prompt to either download the CHM or run it from its current location. Regardless of which option I select, I get the master level CHM and its contents, but (of course) none of the subordinate CHMs get pulled along with the master. Is there some way to make this work, or is it just not possible?A: There is a free- share-ware called HTML Executable © 1998HTML available from G.D.G.Software. This progrem lets you pack all your .chm into one .exe file. On running this file is downloaded, unpacked in a windows/temp directory and started. On closing the temp directory is emptied.
Q: I'm running the HTML Help Workshop 1.1 from Visual Studio 6.0 on my machine, and every time I make the mistake of clicking on the Help tab I get the messagebox "The window name "ProjectHelp" passed to HH_GET_WIN_TYPE has not been specified. <OK>" The cursor turns into an hourglass and the application will no longer respond. I need to kill the Workshop in Task Manager. Naturally, all the changes made and not saved are lost. Selecting Help Topics from the menu work fine. Any ideas?A: You're running into a bug with the embedded window in HCW. There's no workaround (except doing some recoding in HCW, which the HH team hasn't done) so my advice is: don't click the Help tab! The Help tab has been removed in the 1.2 version.
Some notes on this from HTMLHelp MVP Cheryl Lockett Zubak (Work Write - User Assistance from WinHelp to the Web):
* If you decide to go back from HH 1.1b to 1.1a, any Microsoft help least, it's still necessary to use an absolute path.
Q: A lot of help files have links to the Control Panel. How do you define such a link for HTML Help? How do you call the Control Panel?A: This is easy in WinHelp because of the ControlPanel macro. In HTML Help you
can use the ShortCut command of HHCTRL. For example, the following object
tag will show the Display Properties dialog box from Control Panel:
Q: I have an HTML Help project that uses several network drive paths. When I compile the HTML files, the graphics do not display unless they are located in the same directory as the HTML pages that call them. I've tried clicking the "Don't include folders" option in the HTML Help Workshop, but this doesn't seem to fix the problem. I've had similar problems. As far as I can tell, every file that's actually compiled into the .CHM must reside in the same folder as the .HHP or in a subfolder. I'd love to know if anyone's found a workaround for this.A: A CHM file is a self-contained file system, equivalent to a hard drive. You cannot refer to items "above" the root of a CHM file any more then you can refer to items "above" the root of a hard drive. Unlike real hard drives, you also can't access other "drives" other then through an inter-CHM file jump.
Let's say you've got the following directory structure:
and in default.htm you have an IMG tag:
Since \projects\test is where your project file is, that is also where the root of your CHM file is, which means you have tried to reference a file in a hierarchy above the root -- which is simply not possible. That's like saying if my current directory is c:\ then I want to reference a folder one up from that -- you can't because there are no folders higher then the root.
What is supposed to happen at this point is that the compiler recognizes that you have referred to a file above the root of the CHM file. It should compile that file into the root, and change all references to it to reflect that the file is now in the root, not above the root. Unfortunately, that's not what actually happens. In 1.1, the file will be compiled into the root of the CHM file provided the file is on the same drive, but the references to the file will not be fixed, so it still doesn't work. In 1.2, the file will be compiled into the root of the CHM file even if the file is on a different drive. The reference is fixed up if it is on the same drive (technically speaking, the fixup is wrong, but it still works). But if the file is on a different drive, the reference is not fixed up.
Fortunately there's a way around the problem, even for the incorrect fixup that 1.2 does. Instead of referencing your image file as "c:\projects\image.gif" change it instead to "/image.gif". Now add the "c:\projects\image.gif" to your [FILES] section. At this point it doesn't matter whether the image is on the same drive or not. 1.1 will compile this, leave the reference alone, and it will work fine. 1.2 makes all references relative, without paying attention to the root, so the reference will become "../image.gif". This is not correct, but fortunately ITSS which actually handles finding the file in the CHM file will correct the error and find it in its correct location "/image.gif".
One thing to keep in mind when using this approach is that if all files are going to be copied to the root, then it is imperative that you keep all filenames unique. It you try something like adding "d:\art\image.gif" and "e:\art\image.gif", then only one of these files will actually be used, not both.
Navigator 3 opened the CHM directly (it appeared as garbage in the browser window.) To get it to work correctly, I had to configure a helper for the purpose. This has MIME type "application", sub-type "chm". The helper is configured to launch the Application "c:\windows\hh.exe". When I now click a link to a CHM, it opens in the HH viewer.
Q: I was able to get custom icons to work in my Contents with HHW 1.1, but they no longer work in 1.2. Why? How can I get them to work?A: Ralph had stated: "In 1.1, the compiler looked at graphics in paths outside of the CHM file and left them alone. With the 1.2 compiler, if the graphic is on the same drive as the project file, the path is forced into a path relative to the project file -- unless it is prefixed with a file: protocol. That of course breaks your custom icons. The only workaround I can think of that is to prefix the path with file:\\ to prevent the compiler from converting the full path into a broken relative path, or to make certain that your project file is on a different drive then the BMP file."
In October 2001, eHelp MVP Rick Stone found the solution: "When you specify the icon strip file, ensure that it says c:stripname.bmp and not just simply stripname.bmp. (note the absence of the typical backslash after c. This should work regardless of the folder the .CHM and strip are copied to, but it limits the placement of the .CHM on the C drive in order to use the custom strips. If the .CHM and the icon strip file are moved to E: for instance, it won't work."
HTML Help >