This content has been marked as final. Show 10 replies
I have never seen this myself and I have done a lot of context-sensitive help, although I have an older version of RoboHelp. The latest versions of RH have been more directed at WebHelp and single source development, so I don't know what might be added to the CSH source files specifically for those other formats.
The .h and .ali files are text files and need not have any info except the #define MAP_ID mapnumber (.h or .hh file) and MAP_ID=topic name (.ali file).
I actually do all of my context help in Wordpad and don't touch it from within RoboHelp. It might be possible for you to do this as well. It is not as daunting as it might sound as long as you are not making huge changes from version to version. In fact, I find it easier than the RH dialog.
I believe you need to change the encoding in your .h and .ali files from UTF-8 to ANSI. (You can use Notepad to do this.) If either or both files use UTF-8 encoding then you'll encounter this problem.
Thanks for the answers,
I tried saving both the .h and .ali file in ANSI encoding from Notepad, then starting up the Robohelp project and building my CHM right away. Tested it, and same problem is still there - the topic listed on the first row of the .ali file will not work.
We've not noticed this problem in previous versions of Robohelp. We've used X5 for a long time before upgrading to 7 some months ago. Maybe something broke in the Robohelp code when Adobe introduced multi-language support and all that?
Maybe something broke in the Robohelp code when Adobe introduced multi-language support and all that?
That certainly sounds possible. Is compiling outside RoboHelp an option, either with HTML Help Workshop or from the DOS command line (using the command hhc YourProjectName.hhp)? That would permit you to change the encoding of the two files to ANSI without having RoboHelp change them back to UTF-8 at compile time.
Well, I guess the most straighforward workaround is to manually edit and make sure that the ALI-file has a dummy topic on the first row, before building the CHM from Robohelp. It's not every day that we add or change the context-sensitive help parts of the project, so I guess one can make a note of manually checking the ALI-file before building after doing changes to context-sensitive mappings.
We do have to build from within Robohelp since we use conditional build tags and such.
Thanks again for your response!
We've encountered a very similar problem. Seemingly random topics (not just the first one listed on the ALI file) have ceased to function in the context-sensitive sense. Changing the encoding back to ANSI on the .H and .ALI files help. It's just that we've got 35,000+ topics across 20+ help projects (I'd ballpark .hh files at 100+) and many of these files are modified often.
I'll definitely file a bug report, but this has become a big hassle for us. (And a release is due Friday...argh.)
I don't suppose anyone has heard from Adobe on this issue? (I know it isn't likely.)
No news I'm afraid. Just wanted to share with you that we experience a somewhat similar problem with CSH, which appears when we change values of user defined variables; see http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=65&catid=449&threadid =1344542&enterthread=y . We've bug reported the problem to Adobe.
Ah, looks like there's more of us that has similar problems then. Strange that some of us get things to work by saving the .h and .ali files in ANSI format and some not.
Anyway, I've bug reported this with Adobe as well.
OK guys, an update to the "1st row of ALI-file does not work" problem. Hopefully this workaround will help.
Generate your CHM with exactly the same name as your project. So myproject.xpj means your chm has to be myproject.chm. You can rename it after generation.