This may have already been answered, but WebHelp will not display at all on my Google chrome browser. I have RoboHelp 9, and using Google Chrome v.13.0.782.112.m. I checked my other browser, IE8, and WebHelp displays perfectly on there. Any suggestions?
Versions of Chrome starting last summer busted all forms of local WebHelp (HTM or HTML files) to plug a "security hole" - they are unwilling to fix it. Your only workaround (provided you don't want to move your files to a web server (real or fake)) is to modify the Chrome shortcut to launch with --allow-file-access-from-files in the command line. See this blog post about the issue: http://techcommdood.com/techcommdood/chromewebhelp-issue-update-with-t houghts-from-a-hat-vendor/
Ok, now I have another problem: When I generate and view the WebHelp output, everything appears fine, EXCEPT the webhelp screen does not have the 'previous' and 'next' screen navigation arrows (which should appear in the horizontal box above the TOC.I then tried viewing in WebHelp Pro, and though the arrows now appear, they do not work. Is there a setting for this? Or is this another one of those Chrome issues?
It worked, sort of. I added the browsing sequence, clicked the box to enable browse sequence, and yes, the arrows are now there. BUT, they don't work from WebHelp. Interestingly, the arrows appear AND work perfectly in WebHelp Pro output. What gives?
My issue is a bit different. Latest Google Chrome 14.0.835.186 running on Windows 7 Pro (x64) After inserting the string "--allow-file-access-from-files" string to the Chrome Shortcut. we launch our WebHelp system (running on the local PC) like this file:///C:/Multi-DNC/program/webhelp/multi-dnc.htm and get this:
This system is generated using RoboHelp 126.96.36.199 The Multi-DNC Help project topics are fine, but there are (8) other embedded Help systems. If you click on their intial topics, the sub topics appear and work correctly. When the TOC topic compressed, the
My RoboHelp 188.8.131.52 does not have that feature. But maybe that is the answer, if I update to the RH9 will this problem be resolved? Do you use multiple embedded Help files in one system in RH9 with Chrome? If so do you have to compile a special Chrome version? And have different versions for other browsers?
You are talking about creating WebHelp for Chrome. WebHelp is just that, it is not written for any specific browser so I'm not sure what you mean.
Chrome was not supported in your version of RoboHelp and your version of RoboHelp was not supported on Windows 7. I think Jeff's suggestion to try this all out on a separate machine using the trial version of RoboHelp 9 is the way to go.
See www.grainge.org for RoboHelp and Authoring tips
No Peter, I was just suggesting that he try RH9 to see if it had any impact on the project when he tried it with Chrome. Frankly, I was suspicious that it was a RH issue at all - if RH9 had no effect, then the issue was likely to be something in Chrome. If it did fix it, then it's a RH7 issue.
BTW - I wasn't aware that any version of Chrome was supported - in which version did that change?
I just talked to a support engineer and they told me Chrome was not supported in RH9. I tried installing HM2GO but I am not sure how to form the URL, since my WebHelp index file is local (///file:C:/ etc.)
I tried calling the index file using Chrome with the --allow-file-access-from-files argument but the frame contents still will not load. I was able to view it with a freebie local webserver, but that won't work for our customers looking to view help files installed with the product, will it?
Thanks for everyone's help
The Support Engineer is wrong if they stated that Chrome is not supported but is that what they said? Chrome is supported from RoboHelp 9 but you need to understand it will not run locally so to that extent it is not supported. When the help is on the server, your customers will be able to view it using Chrome.
If you are installing webhelp locally for your customers, then I believe your engineers can set it up to run within the HM2GO but whether or not that is acceptable is another matter.
See www.grainge.org for RoboHelp and Authoring tips
I have not tried compiling my multiple Help files that are done in RH7 in the Trial version of RH9 as yet, I will do that. If that resolves the Chrome browser issue, great, if not, our software product uses its own ActiveX based Web Server so if I could form the URL correctly for Chrome that might work too.
If using the argument method, you have to change your Chrome shortcut first & then open the index page of the help. This "security change" of Google's affected all providers of webhelp, not just RH. In my case our product gets installed on the client's LAN server and it still affected us. I had to tell people that they couldn't use Chrome to view it - IE & FF were fine.
Yes, it still falls into Chrome's definition of "local" therefore = "dangerous" ;>)
I know that the argument method of launching works, but it was easier to tell our clients to just use another browser.
Yes - the support engineer told me Chrome was not supported with RH9. I tried to politely tell him he was wrong, but his response did not change.
Our hosted WebHelp works just fine in Chrome for our customers. For the WebHelp that gets installed with our products, we'll just have to point them to another browser or access the hosted WebHelp on Chrome.
Thanks for all your help, folks.
Europe, Middle East and Africa