Skip navigation
jrszin
jrszin Calculating status...
Currently Being Moderated

Javascript error prevents TOC, Index, Search from displaying

May 3, 2012 7:55 AM

Tags: #error #toc #javascript #robohelp_8 #webhelp #toc_error #not_displayed

I generated webhelp from my RoboHelp HTML project and got a javascript error (this.maCom[...]' is null or not an object) when viewing the result. See below for the full error text. As a result the TOC, index, and search do not display. The javascript error can be found in the browser status bar which indicates "Error on page." I found that if I viewed the result from robohelp, the browser that launched shows the TOC, index, and search, but has a security warning about a restriction from running scripts or ActiveX controls. However, when I move the generated webhelp to my production server, the help does not have the security warning, but does produce the error so that the TOC, index, and search do not show. I had performed the same process to generate webhelp about 8 months ago but did not have any error whatsoever. As a matter of fact, that version is still in production and works fine.

 

In my research of the problem, I found this is the same error as forum message 4063663 (http://forums.adobe.com/message/4063663). I didn't have a second system with RoboHelp to be able to get another whphost.js, however, I diff'd the generated file with the one found in template_stock and found only two lines different. Those differences were only replacing a couple of variables with static text so I don't think replacing this file will solve any problem for me. This was the only forum message I could find that addressed this issue.

 

I was originally on RoboHelp 8.0.0 when I first encountered the problem, but went ahead and patched to 8.0.2 and still had the same problem. I even created a new simple project. Once I moved the simple project to the production server, it also would not display the TOC, index, and search.

 

The odd thing is that just 8 months ago, I used the same process to generate (on 8.0.0) the webhelp without any error. The only thing I can come up with is there was a WinXP patch that affected the webhelp generation. By the way, I also tried this in Chrome and that also produced the error.

 

I'm not sure what is causing this problem or how to resolve the problem. Any one have any ideas?

 

Versions:
RoboHelp 8.0.2
Windows XP
IE 8.0.6001.18702CO
Chrome 18.0.1025.168 m


Javascript Error
-------------------------
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; InfoPath.2; .NET4.0C; .NET4.0E)
Timestamp: Wed, 2 May 2012 16:32:00 UTC


Message: Object expected
Line: 344
Char: 2
Code: 0
URI: http://server1/robohelp/whphost.js


Message: 'this.maCom[...]' is null or not an object
Line: 171
Char: 3
Code: 0
URI: http://server1/robohelp/whphost.js
--------------------------

828 Views   5 Replies   Latest reply: jrszin, May 8, 2012 12:07 PM
 
Replies
  • Peter Grainge
    Currently Being Moderated
    1. Peter Grainge,
    May 4, 2012 1:49 AM   in reply to jrszin
    Report

    When you have the help local I think what you are seeing is the yellow information bar. It's an IE thing and if you allow those files to run, the help should work, other issues apart.

     

    Once the help gets to the server, that will not happen. However then you see another issue. See Item 6 a http://www.grainge.org/pages/snippets/snippets.htm#webhelp as that could be the problem.

     

    See www.grainge.org for RoboHelp and Authoring tips

     

    @petergrainge

     
    |
    Mark as:
  • jrszin
    Currently Being Moderated
    2. jrszin,
    May 7, 2012 9:26 AM   in reply to Peter Grainge
    Report

    I only mentioned the local to show the difference between the local and the server. The local is not an issue for me. It shows the TOC, index, and search.

     

    I suspect your suggestion may not solve the problem. Today, the same server serves up my production version of the help just from a different folder. The TOC, index, and search work just fine from the production location. If the MIME types were an issue, my production version would not be served up. By the way, the production version was the prior webhelp compile generated (about 8 months ago) from the same system and same robohelp version.

     
    |
    Mark as:
  • jrszin
    Currently Being Moderated
    3. jrszin,
    May 7, 2012 1:07 PM   in reply to jrszin
    Report

    After further research and tests, I discovered the Security Update for RoboHelp 8 and 9 (http://www.adobe.com/support/security/bulletins/apsb11-23.html) posted as an announcement that I had not seen before. I had used the updates feature in the product, but that said I was up to date and did not include this update.

     

    The two javascript files in this patch solve the problem. The TOC, index, and search now display.

     

    Update:
    As I further researched the problem (while writing this response), I found files that were newer than the latest security patches I was aware of. In addition, I discovered that my security organization decided to patch with APSB12-04 without me knowing about it. This patch is why my 8.0.0 installation magically quit working. As I look at the security announcement, the bulletin did not include any prerequisites of specific versions the patch can be applied to (8.0.0, 8.0.1, or 8.0.2). Adobe, please give more information on the bulletins so that organizations that auto-deploy will be forced to know what is running before updating. Information like whether they apply to all Robohelp 8 versions or just a specific version. If APSB12-04 was meant to be applied to all 8 versions, then it did not work. It actually broke my installation of 8.0.0 for the generation of webhelp as well as subsequent installation of 8.0.1 and 8.0.2. It looks like they did a better job for APSB11-23. Maybe the security updates should be some sort of service pack that has an installation and a back-out process. Right now, my security organization has overwritten the files based on the specification in the security bulletin.

     

    I am going to try to patch with APSB12-04 again since I have updated the base to 8.0.2 to see if I can still generate webhelp. If I can't view the TOC, I'll have to remove it once again and be "out of compliance."

     
    |
    Mark as:
  • Peter Grainge
    Currently Being Moderated
    4. Peter Grainge,
    May 8, 2012 12:46 AM   in reply to jrszin
    Report

    No good asking Adobe anything here, it is a User to User forum. This is something you need to take up with Adobe. Installation issues are supported free and I think you could argue this is an installation issue.

     

    See www.grainge.org for RoboHelp and Authoring tips

     

    @petergrainge

     
    |
    Mark as:
  • jrszin
    Currently Being Moderated
    5. jrszin,
    May 8, 2012 12:07 PM   in reply to Peter Grainge
    Report

    I agree with you. I just added it just in case someone from Adobe was cruising the forum and might take on the issue.

     

    Thanks for responding to this post. Your post made me think about the fact that I already had a working version which helped to rule out the server configuration. And that led me to looking at the individual patches as well.

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points