Merged help projects and context sensitiviy

Check what you plan to do with your developers. This affects their calls to the help.

The two are not readily interchangeable. WebHelp is the format you should use if the help is to be server based and HTML help is the format for locally installed help.

For WebHelp we use the startpage'htm#path/targettopic.htm method and it works well. See my site for more information.

Hello and happy New Year. Has anyone successfully implemented context sensitivity with merged projects in RH7? If so, which method did you use? Thanks.

Hi, again,

> 1. In my case, I don’t have bookmarks as part of the context sensitivity
> path. I want an entire html page to display. So, I don’t have to use the
> Dummy_Usage line, correct?

No, the Dummy_Unused entries were required to work around a limitation in the Helpware solution. Now that I test this again, though, the problems I encountered yesterday for which adding the Dummy_Unused entries was the solution don't seem to be recurring. So, probably best to forget about this for the time being.

> 2. What should the master project’s .h file contain?

It should contain all the context help mappings for all the help files — master and slaves. So, to the mappings for the master help files you would append the entries from the .h files for the slaves, like this:

// Master help mappings

#define IDH_MASTER_TEST1 1
#define IDH_MASTER_TEST2 2
#define IDH_MASTER_TEST3 3

// Slave #1 mappings

#define IDH_SLAVE1_INDEX 4
#define IDH_SLAVE1_ANOTHER 5
#define IDH_SLAVE2_INDEX 6

Likewise, the alias (.ali) file for the master project should contain the aliases for all the help files. But in this case you associate the topic IDs for the slave topics with the redirector file, to which you append the appropriate IDs again, like this:

; Master help aliases

IDH_MASTER_TEST1=master1.htm
IDH_MASTER_TEST2=master2.htm
IDH_MASTER_TEST3=master3.htm

; Slave #1 aliases

IDH_SLAVE1_INDEX=redirect.xhtm#IDH_SLAVE1_INDEX
IDH_SLAVE1_ANOTHER=redirect.xhtm#IDH_SLAVE1_ANOTHER
IDH_SLAVE2_INDEX=redirect.xhtm#IDH_SLAVE2_INDEX

Then, in the redirector file, you set up a series of mappings between these topic IDs and the corresponding topics in the slaves, like this:

if (Code == "IDH_SLAVE1_INDEX") URL="its:Slave.chm::/slave1.htm";
else if (Code == "IDH_SLAVE1_ANOTHER") URL="its:Slave.chm::/slave2.htm";
else if (Code == "IDH_SLAVE2_INDEX") URL="its:Slave.chm::/slave3.htm";

This probably sounds more complicated than it is in practice. Once you've got to grips with how the method works, it's actually quite straightforward.

> 3. I notice that RoboHelp wipes out or adds to the edits I make (via
> EditPlus or Notepad) to the .hhp file – why is that? I noticed this days
> ago so I always have a backup to replenish my edits in the real .hhp file.

I'll have to pass on that, as I'm not currently a RoboHelp user. Perhaps someone else following this thread can comment.

> 4. Will context sensitivity be easier with RoboHelp 7?

As far as this issue is concerned, I doubt it, because we're using an under-the-hood technique to work around limitations in the HTML Help format. Users of Flare, Doc-To-Help, and all other help authoring tools have to jump through the same hoops to get context sensitivity to work seamlessly in merged help projects.

Just to repeat what I said yesterday, I have a sample help collection illustrating this technique if you'd like me to send it to you off-list. Maybe that will make things a little clearer.

Pete

Hi, msmanitoba,

> How would using the Master TOC affect context sensitivity?

If you pass context help calls to a slave .chm file directly then users don't have the means to browse beyond the contents of that file to the other help files in the collection. The trick of Solution #3 is therefore to display the TOC of the master .chm file in each of the slaves so that users can get to topics in other help files if they wish. In effect, there shouldn't be any noticeable difference between the appearance of a slave .chm file and that of the master file.

Whether or not you use this technique shouldn't have any effect on context sensitivity, though.

> For example, can I eliminate "its:" protocol?

Yes, you can do this, but use of this protocol will not cause the target topics to display in Internet Explorer if you've set everything up correctly.

> What the Helpware site doesn't explain is that the ALIAS section of the
> .hhp file must contain at least one bookmark-free reference to the
> redirect.htm file

I suspect that this is the reason why you're running into problems with this method. If you look at the sample .hhp file in the "Solution #1: Mappings on the Help Side" section of the Helpware article you'll see that every alias to the redirect file has a bookmark appended to it:

IDH_SLAVE1_INDEX=redirect.xhtm #IDH_SLAVE1_INDEX
IDH_SLAVE1_ANOTHER=redirect.xhtm #IDH_SLAVE1_ANOTHER
IDH_SLAVE2_INDEX=redirect.xhtm #IDH_SLAVE2_INDEX
IDH_SLAVE2_ANOTHER=redirect.xhtm #IDH_SLAVE2_ANOTHER

In the test files I've created (and that I can send on to you if you want), the fact that there isn't an alias without a bookmark causes the method to fail. So you'd need to add an additional alias like this:

Dummy_Unused=redirect.xhtm

and map the topic ID to an unused context integer in the map (.h) file, like this:

#define Dummy_Unused 0

Pete