Relative merge path

[Fly_Molo]

This project is for compiled HTML Help, using RHX5 (and the RH6 trial). Forgive me if this has been answered before, but searches in and out of Adobe haven't turned up much for me.

I'd like 'Project A' to merge to 'Project B' while maintaining a relative merge path. When delivered, these two .chms will be installed in the same directory. As it is now, RoboHelp automatically changes the path I specify in the HHP file to a full path. Chances are good that users will not use the same directory structure for storing help as I. RH5 will only leave the HHP file alone if there hasn't been a change in the project since the last compile was started.

I've managed a work around for manually avoiding this issue each time I compile, but I see that nothing has changed for RH6 (trial). Furthermore, the command line compiler triggers this automatic merge path change each for each compile regardless of the unchanged state of the help project. Assigning a read-only file attribute to the HHP file means very little to RoboHelp.

Am I missing something that I should have set up earlier? I'd appreciate any input any of you may have. Thanks.

//Lucas

[Peter Grainge]

My understanding of CHM help is that the merge requires all the CHM files to be in the same directory and this is a requirement of the Microsoft Help Compiler, rather than RH. I thought the link was based on the file name and then the path and it only looks for the filename in the same directory, if not found then it gives up.

Are you saying you have had merged CHM help running with the files in different directories?

[Fly_Molo]

Hi Peter,

No, I have merged help running in the same directory. Since the two CHMs are in the same directory, I think that the path specified for the merge should be relative. Instead RoboHelp changes to a full path when I begin my compile.

I generally have to edit the merge section of the HHP file to look like this:
[MERGE FILES]
projectb.chm

Manually modifying the path produces the desired result, but is ineffecient and a bit tiresome.

When I compile through RoboHelp, RH modifies the HHP file to look like this:
[MERGE FILES]
C:/MISC_HELP/FOLDER_NAME/projectb.chm

Of course, a Help user is unlikely to store the Help in a directory as such, and the TOC doesn't display as I intended.

I tried compiling the projects with the HTML Help Workshop and it doesn't change the path, but I lose the pre-processing that RoboHelp does. In my original post I outline that the RH6 command line compiler behaves this way, and that I can't find a workaround for this issue--maybe I should cross my fingers and wait for RH7? Thanks for your interest.

//Lucas

[RoboWizard]

Hi Lucas

I believe that what you are seeing is a red herring. I put this to the test as follows. In my RoboHelp HTML classes, I describe the Merging process for .CHM files and have worked up a small demonstration I use. I place all my projects in a folder named "Rick".

I have a file named "Seroj_merge_master.chm" where I look for a file named "Seroj_merge_slave.chm". These are both in the same folder. I illustrate that if I simply rename "Seroj_merge_slave.chm" to something like "Seroj_merge_slaveMM.chm", the master isn't able to find it, as it is expecting the former file name. I then rename it back and illustrate that the merge works.

If what you are saying is true, that the file will look in the explicit path, my test should be valid. Here's what I did. I simply renamed my "Rick" folder to "Rickst". Assuming your suspicions were true, the master would then be expecting to find the slave in the following path: "C:\Rick\Seroj merge master\!SSL!\Microsoft_HTML_Help" and since the name is now different, that should break things, no? In fact, the master still found the slave after renaming the folder.

Additionally, I also believe it's entirely possible that as long as Windows knows where the slave .CHM file is, you may locate it anywhere on the hard drive and the merge should occur. To easily to this, a tool exists in the Tools tab of RoboHelp HTML. It's called HTML Help Registration. Really, it's a simple front end that allows you to easily modify the Windows Registry where it lists all the .CHM files and their respective locations.

Hopefully this helps... Rick

[Fly_Molo]

Thanks for the reply Rick. I am thinking that I must not be very good at explaining my problem.

I am not concerned about my slave project finding the master during the compile. I am concerned that the end user will not have TOC (and other merged functions) that I intend. I tried out the directory renaming test that you suggested here without getting the desired result. If, after the projects are compiled, the master and slave .CHM's location relative to each other is changed, the Help is broken (for lack of a better term).

While the HTML Help Registration tool is nice and simple, it did not fix this issue nor did it list all the applicable help files on my machine.

If the .HHP file is my red herring, what else should I be chasing. When I manually edit the .HHP file outside of RH, I get the result I desire. This isn't a problem solely for me and my machine--the other members of my group here experience the same problem with other help projects built with RH.

[RoboWizard]

Hi there

I suppose then it's obvious I'm misunderstanding your issue. For starters, it's typically not an issue with a slave "finding" a master either during the time its compiled or at run time. For all it knows (or cares), it's the only one in the game. It's typically the Master you are concerned with being able to sense a Slave file is present. Even then, you would care less at compile time, as it normally just contains a stub or pointer in its TOC that triggers looking for any subs that may be present.

I'm guessing that since you aren't seeing the same results as I am, you are referring to a Master being in one location and the TOC does not reflect the combined TOC of Master and Slave when you view it. Normally, it's easiest to keep both files in the same folder just for the sake of simplicity.

I'm not sure what to advise here. My installation is pretty basic. I have no special tweaks in place that I'm aware of would cause any change in the way my own PC works as opposed to yours. What is the relationship between the master and slave? Are they normally in the same folder or are you placing them in entirely different folders?

As for the HTML Help Registration "not listing the applicable files", keep in mind that not all .CHM files will be registered in this manner. Only if measures have been taken to include them will they show up in this list.

Cheers... Rick

[Fly_Molo]

quote:

---

Originally posted by: RoboWizard
I'm guessing that since you aren't seeing the same results as I am, you are referring to a Master being in one location and the TOC does not reflect the combined TOC of Master and Slave when you view it. Normally, it's easiest to keep both files in the same folder just for the sake of simplicity.

I'm not sure what to advise here. My installation is pretty basic. I have no special tweaks in place that I'm aware of would cause any change in the way my own PC works as opposed to yours. What is the relationship between the master and slave? Are they normally in the same folder or are you placing them in entirely different folders?

---

Yes, both master and slave are always in the same folder. I take it that it isn't possible to prevent RH from modifying the [MERGE FILES] section of the .HHP file.

I'm very appreciative of your effort, thanks!

//Lucas

[Amebr-ke0mH4]

Hi Eh-nonymous,

We have this problem with a master we create. It occurs for a project in Microsoft Visual Source Safe. I seem to remember someone saying that it had been acknowledged as a bug by ehelp (or maybe macromedia, I can't remember exactly when this was posted) for source controlled projects.

I can't locate the topic in the forums, unfortunately - the search seems to be doing "exact phrase" matches for me at the moment (plus most of my "favourites" come back with a topic not found message).

Again unfortunately, I don't have a solution, apart from compiling, removing the path from the hhp and recompiling each time we release the master.

[Fly_Molo]

Hi Amebr

That is more or less the method we still use today.

Instead of compiling twice however I found a marginally shorter way to accomplish our goal. As opposed to using the 'Generate Primary Layout' button on the toolbar I choose File Menu -> Generate Primary Layout and wait for the Layout dialog to appear. Then I can manually remove the path from the HHP, save the HHP, then compile by clicking the Finish button on the dialog.

It is during that dialog (HTML Help Options) load time that RH inserts the full path to the slave project.

That might save you a few seconds I suppose, maybe.

Lucas

[Guest]

Lucas, you and Amebr are correct. We've been building merged .chm Help with a script using RoboHelp x5. After the first compilation, we modify the HHP needs to remove the absolute path, and just leave the <project_name>.chm. Then we recompile.

Our problem is that under RH6 command line compilation (a major selling feature of this release for us), this doesn't seem to work any longer. The absolute path is reinstated during compilation. Our primary issue is that the indexes aren't being merged.

[Fly_Molo]

That's right Marcus, it is a sticking point for me as well. The command line utility doesn't give the user the opportunity to work around this. So, to make the CLI somewhat useful I use it to build everything once, decompile all the generated CHM files, fix the HHP with a command-line find and replace tool, then compile everything again with the standard Microsoft HTMLHelp compiler. I just have to make sure that all the right HTMLHelp-specific files are in the working directory when I compile the second time.

Let me do it my way Adobe, please.

Lucas

[Guest]

Have you tried expirmenting with a modified SSL?

.MW

[Fly_Molo]

I've tried, albeit unsuccesfully. Sorry.

Lucas