4 Replies Latest reply on May 1, 2008 6:57 AM by HKabaker

    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?
        • 1. Re: full text search issues with whlang.js file coding
          HKabaker Level 2
          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
          • 2. Re: full text search issues with whlang.js file coding
            YBacon Level 1
            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.
            • 3. Re: full text search issues with whlang.js file coding
              Peter Grainge Adobe Community Professional (Moderator)
              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.

              • 4. Re: full text search issues with whlang.js file coding
                HKabaker Level 2
                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