I cannot confirm. The attached chm project does contain the index. It was created this way (on Windows):
- Unzip the files of the chm project to some folder.
- Compile chmcmd and copy the binary to this folder.
- Execute chmcmd moon.hhp
- chmcmd will generate some warnings due to missing .js files, but this does not affect the functionality of the generated chm file.
- The Microsoft chm viewer opens and displays this chm file correctly.
When using HTML Help Workshop we get a folder inside the chm called $WWKeywordLinks but this folder is not present when using chmcmd, making difficulty to use it's generated .chm integrated with the software.
Please ignore my ignorance: How can I see that keyword links are missing? what do I have to do to see the error? Please give step-by-step instructions.
I compiled the chm file from your sources by chmcmd of fpc trunk and of fpc 3.0.4 (there were some recent changes) as well as by MS Help Workshop. All the chm files created look very similar, even in size (+/- 30 kB).
chmcmd reports a long list of anchors not being defined. Are you sure that the source html files are correct?
You need to set the "Binary Index" option in the project to "Yes" (maybe also "Binary TOC"), then the $WWKeywordsLinks folder is created. Don't know why that isn't an issue with the Microsoft tool, but chmcmd respects those options.
Isn't the binary index just a binary version of the same index data which are in the file anyway?
@eriOo: What exactly is the problem? When you press F1 (i.e., call for help) then the help window does not show? How can you be sure that the bug is in chmcmd and not in your application?
I was able to use the chmcmd-created help file of your application in the demo of the Lazarus chm help system,(lazarus)/components/chmhelp/democontrol/ContextHelpDemo.lpi). Therefore I tend to believe that the chm files were created correctly with chmcmd.
Ok, it appears I made a confusion with the .hhp files and am wrong. I am sorry for the trouble. I will test the options on the xml file and confirm here which option worked for the KeywordLinks generation. This chmcmd tool is awesome and allow cross-platform chm help generation. I am really grateful for this project.
Note there is something like real keyword links (not just the name in the file list), but IIRC those look like activex objects (objects with a guid) in the source, and they are rare.
@wp: if you uncompress the chm file with unzip or whatever you'll see the $WWKeywordLinks directory if "Binary Index" is enabled; otherwise this directory will be missing. In case of the Microsoft Help Tool Builder this might be generated nevertheless or something else is different...
@eri0o: yes, please report back if you managed to fix/verify this on your side, so that we can resolve this.
Here we have the build results for both the chm files generated by chmcmd and HTMLHelpWorkshop - I booted a Windows machine just to run the HTML Help Workshop hhc.exe.
(note, the .hhp project zipped here is saved before we swap the No to Yes on the appropriate fields using our script make-chm-from-htmlhelp.sh)
Ok, so the result is that marking binary TOC Yes and Binary index Yes I get both folders I wanted: $WWAssociativeLinks and $WWKeywordLinks .
But the resulting BTree from chmcmd is comming nearly empty - you need an Hex Editor to verify that. If you look the BTree on the file generated from HTML Help Workshop it will be correctly filled.
So there is something different.
Now the bad news for me. It didn't matter. Even having everything generated through HTML Help Workshop from the project generated through sphinx, the resulting chm didn't work for my goal - using Help.ShowHelp KeywordIndex on .NET.
So I think there is indeed a bug on chmcmd, correclty generating BTree under $WWKeywordLinks, but it is not what is affecting me.
So, I'm not entirely sure what the problem is in this case, but I had previously run into a problem with full text search in the CHM writer. Basically that it didn't include words that only occurred once.
If it is related can you try the patch I've attached?
It's a fairly contained project, so you can just get the FPC sources, apply the patch, and then copy all files from the "packages/chm/src/" to a separate directory and then compile chmcmd.lpr in that directory.
I tested a bit yesterday, and the attached hhex3 does look up files for the workshop version, and not for the chmcmd version. And indeed the trees look empty.
I also have a hunch about the reason of those 1/5th. Possibly workshop makes simply more nodes and chmcmd should follow. This probably never was noticed because our tests files used less nested entries in the index.