WebHelp context sensitivity breaks when installed locally (all browsers)

[ENTRGWH]

I'm currently producing Webhelp using RoboHelp 2019 (classic) version 14.0.9.004 on Windows 8.1, however I first experienced the issue using RoboHelp 2017 (on Windows 8.1). Context sensitivity works fine if the help is opened from a web server or from a file server. When opened locally, everything is normal, no problems with Search or TOC etc. except it always opens to the default page--no context sensitivity. When the help opens, the context sensitive piece of the help call is missing. This is true for IE, Chrome, and Firefox.

I've tried adjusting various settings in Internet Options (through IE), setting the Mark of the Web, and (out of frustration) setting combinations of pretty much every other option on RoboHelp's Output Navigation page above the toolbar buttons. No luck.

I've seen other similar posts but they seem to occur with a specific browser or are missing components like the TOC. Not the case here. Everything works but the context sensitivity.

Does anyone have any suggestions?

[Jeff_Coatsworth]

What method are you using to call the CSH topics?

[ENTRGWH]

Not sure what level of detail you're looking for. The software help link passes a string to WebHelp that's mapped to a help file. When installed locally the software gets the location of the help from a path that is stored in the registry. An example of a path would be "file:///c:\help/. The help link adds the index file and string to the call. That piece (index and string) are for help stored locally or on a web server. Only the path to the location of the help is different.

[ENTRGWH]

Correction an example of the help call is more like: file://C:/help/index_csh.htm#topicnumber=<string>,withnavpane=true 

[ENTRGWH]

One of our developers found a workaround for this problem. It involves changing the way that the help call is sent to WebHelp rather than changing anything in RoboHelp or Windows options. 

[Jeff_Coatsworth]

Can you let us know what the changed call is now?

[ENTRGWH]

Sorry for late reply. 

The workaround wasn't actually a change in the format of the help call. It involved writing the call to a temporary file and submitting the call to the WebHelp from there. I don't actually know the specifics (or why it made a difference). It also doesn't work with all browsers.