Script errors whenever active WEB page link is clicked in CHM file

[TechWriterKat2]

I have been researching this problem, and I have hit a wall. We are using ancient TCS 5.0, and we are still generating and  CHM files, which various web searches claim "have been decprecated," but it turns out they really haven't, except in Microsoft Dynamics, which we aren't using -- sorry for the ramble. Anyway, the following variety of error messages pop up when I click on a link to our company's WEB page from our CHM file -- It doesn't happen on every PC. Sometimes it looks like this:

Sometimes it looks like this, which requires me to End the task in Task Manager: 

For now, we are removing these links from the CHM, but keeping them in the soft copy PDF version. I have been tasked with researching what "replaces" CHM, and how it will work with our context-sensitve help links (map IDS in the code).

Suggestions?

Thanks

[Amebr]

There's no modern "single" file help file any more. What replaces chm is a website, basically. In Robohelp terms that would be the Frameless output in the latest version of Robohelp. The website can be deployed to local computers, but I've never had to do that. @Jeff_Coatsworth might have a better idea of what's required.

Peter Grainge details old vs new URL help calls on his site. He only mentions the Robohelp API method, but it's conceptually pretty similar to the chm call and your developers should be able to figure it out from the javascript files that are installed with RH, if they want to use that method: https://www.grainge.org/pages/authoring/calling_help/calling_help.htm

[Peter Grainge]

To add to @Amebr's thoughts and comments...

CHMs have not been deprecated in the sense they will not work. What has changed is that in 2004 Microsoft blocked their use in networks. I doubt that is the issue here as I would expect you to have posted about that way back.

Another point to consider is Microsoft stopped distributing the compiler a few years back. I don't know if that will prevent Adobe distributing it in the future.

Adobe did pilot an exe type of help that was designed to be installed on users machines. It wasn't as polished as it should have been on release but the main problem was some vociferous author feedback. They saw installing an exe on user machines as an issue and the noise did influence others that it was a bad thing. In my view it should have been given more of a chance to see if installing an exe was a real problem. 

There are two alternatives that you can consider. Responsive and Frameless.

Responsive was Adobe's first shot to add to the WebHelp format that came with Classic versions of RoboHelp. That had reached the end of the line in that it contained a lot of code that was not compatible with HTML5 and CSS3 standards. It gave new designs and added functionality. 

Frameless then came along to provide a form of help that worked better with Google search than responsive could. It also offered more features and more customisation. That is where Adobe will now focus development and I strongly recommend it as the option to consider.

Both type of help can be installed on a webserver (not a fileserver) or on a user's machine. I believe that frameless might be a little slower on a local machine but I have not seen any really noticeable difference.

Yes your calls will need to change.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Jeff_Coatsworth]

We distribute a single exe file to install the help system for one of our products on clients' local LAN servers (we haven't pulled the trigger on putting the help up on the web yet). The exe is basically a self-extracting sort of zip file that has some smarts to it so you can point its unpacking into a specific folder. Our software then looks into that folder to launch the help in their browser.