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?
Chrome 18.0.1025.168 m
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
Message: 'this.maCom[...]' is null or not an object
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
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.
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.
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."
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.
Europe, Middle East and Africa