full text search issues with whlang.js file coding

[YBacon]

I'm wondering if anyone else is encountering an issue where a javascript error is preventing the search feature in webhelp output from working. The output and search was working fine a couple of weeks ago, but just recently stopped working.

I get the following error from every browser I try the help in:
Line: 265
Char: 18
Error: Unterminated string constant
Code: 0
URL: <path>\WebHelp\whfbody.htm

There's nothing wrong with this file, but looking through the .js files it calls, I discovered that the whlang.js file has a couple of errors. The first is that the terminating (I think?) charcters "; are on a separate line than the string constant:

gaFtsStop[60] = "over
";

The second error is item 63 in this section has an unknown character in it instead of an "o" such that the browser is reading it as gaFts Stp instead of gaFts Stop.

When I fixed these errors, the search functionality works fine. The problem is, I don't know why RoboHelp is producing this file with all of these errors in it, and why it's doing it now when it used to work just fine. I can't find anything on the web or in RoboHelp's help about this, so I'm wondering if anyone else has a) come across it b) fixed it, and c) got RoboHelp to stop writing a broken file.

Help, anyone?

[HKabaker · Accepted solution]

YBacon,

Welcome to the forum.

I have seen the split line phenomenon before, and, yes, it confuses the js code that uses it.

The original whlang.js file is in
C:\Program Files\Adobe RoboHelp 7\RoboHTML\Help\en_US

or, if you're doing FlashHelp,
C:\Program Files\Adobe RoboHelp 7\FlashHelp SDK\Help


Check in those files first. My guess is that you won't find anything wrong.

This is the default "Stop" and "Ignore" lists, in project .stp and .ign files that get updated when you add words or phrases under Project Settings > Advanced.

If the templates are good, rename or remove the projectname.stp file in the project directory. RH should re-create a default version. Even though your examples are from the stop list, maybe the projectname.ign file is involved.

Harvey

[YBacon]

This fix worked perfectly. Hooray!

Do you happen to know *why* this happens? If it's something I'm doing, like storing the project and output files on a separate drive than the one on which RH is installed, I will gladly change my behaviors to keep RH happy.

In any case you've been a great help. Thank you.

[Peter Grainge]

If your project is on a local drive, or an external hard disk, that is OK. If it is on a network drive, then unless you are using source control, move the project locally.

[HKabaker]

I agree with Peter.

However, I did see the split line problem once or twice, and I never stored projects on a network drive, and always generate to the local hard drive. I'd think generating across the network would be as safe for WebHelp as publishing. On the other hand, we've heard about problems trying to generate print doc across a network.

Can't recall the file names with split lines, but I think it was one of the search database files beginning with whft......

I did move some projects from one PC to another via the network, but can't say whether this caused the change. From time to time I read advice saying it's best to zip up the entire project directory before sending it across the network, and unzip it at the destination. Maybe this has something to do with the split lines, but I don't know enough to explain why it might be so.

Harvey