Cannot Open the file: mk:@MSITStore when Compiling Master

[Jodie Boedigheimer]

I have a master project.
I've linked approximately 1300 other projects to it via a master TOC.
All works fine and dandy. No errors, final output .chm opens just fine and presents as expected.

Then I add another book with approximately 50 projects in it to link to the master.

When I try to view the final output, I get the following error:

Cannot open the file: mk:@MSITStore:etc. etc. etc.

The etc. just goes on to list the path to the master.chm file.

I'm going through each project in the offending book and checking the links in every topic to see if there is one with the older external mk:@msitstore link.

Does anyone have any other ideas for me to try? Something that might be faster to try to resolve the issue?

Thanks
Jodie

[Pete Lees]

Hi, Jodie,

There are some limits on the number of slave .chm files that you can merge into a master .chm file. It used to be the case (and maybe still is) that the TOC of a master file could contain a maximum of 550 "include" statements to the slave files. Similarly, the [MERGE FILES] section of the master's HTML Help Project (.hhp) file could list a maximum of 1148 slaves. (The function of this section is to list the .chm files whose index and full-text search data is to be merged with the current one.) If you try to go beyond these limits then the compilation usually breaks down, resulting in either no .chm file or a corrupt one. Could this be true in your case?

The "Cannot open the file: mk:@MSITStore:" message is just the catch-all message that Windows displays when it cannot open a .chm file, usually because the file is corrupt. You shouldn't read too much into the reference to "mk:@MSITStore:", as Windows continues to use this protocol to some degree. For example, if you right-click the topic pane of a working .chm file and then click Properties on the context menu, the address that is shown in the Address (URL) field is prefixed with the mk:@MSITStore: protocol.

It's possible to merge TOCs recursively — the TOC of one .chm file can be included in the TOC of another, which can be included in a third TOC — so this may be one way to work around the problem. However, this doesn't work for the index and full-text search data; only the first level of nesting works in that case.

Pete

[Jodie Boedigheimer]

ACK! That's it . . . the 1148 for the merge files was causing the problem.

So what you're saying about the recursive thing . . . is the following true.

We have 36 modules. So what I could do is create 36 "mini" masters . . . one for each module. For example:
AP
AR
OE
IC
WT

and so on.

And withing each of those module projects, I can create a master TOC that links the individual TOCs of the projects for that module. For example:
AP
APAC
APET
APAO
AR
ARRT
ARET
ARAO
OE
OEET
OEIO
OEEPI

and so on.

Then, I can create a real live master that links to the TOC in each of those mini masters. For example:

Master
AP
AR
OE
IC
WT

That way, each mini master takes the burden of some of the merge, and the main master takes only the burden of the 36 module merges?

Does that make any sense?

Thank you for your response.

Jodie

[Pete Lees]

Hi, again,

Yes, that's exactly right. The aim is not to exceed the 550 limit on the number of "include" statements in any one TOC and the 1148 limit on the number of file names in any one [MERGE FILES] list. A help collection that comprises one master file and multiple slaves, each with multiple sub-slaves merged into it, could enable you to achieve this.

The downside of this arrangement is that the index and full-text search functions in the master help file don't operate across more than one level of merging. So, in your example, the index keywords in the sub-slaves APAC and APET don't show up in the master file's index, and a search that you conduct from the master file doesn't find any matches in APAC and APET. This has been an issue in HTML Help ever since Microsoft made the format available. The workaround is to add the names of the sub-slaves to the master's [MERGE FILES] list, but of course this defeats the object of the exercise; you've been forced into the extra level of merging precisely in order to reduce the number of files listed in the [MERGE FILES] list.

If it's at all practical to do so, the best solution is probably to reduce the number of help files in your collection so that you don't breach these rather arbitrary limits. But I realise that this may not be very desirable or easily achieved.

Pete

[Jodie Boedigheimer]

The multiple levels of master/slaves worked - woo hoo!!!

Unfortunately, reducing the number of projects isn't an option - it's a legacy help system that is being moved to a new interface without the same CSH capabilities. So I had to create a workaround - which was the master/slave thingy.

The good thing is, it does not use an index and a search function isn't necessary. I know, you all will not believe that . . . but with this old archaic help system and its layout, it's true

Thank you so much for your help! You saved me tons of time and headache . . . I really appreciate it.

Happy New Year!

J