CSH with WebHelp

[sarrants]

We are planning on switching from HTMLHelp CHM to WebHelp, and serving the documentation to our users. However, a small number of customers do not allow internet access. If we give them the WebHelp and use file:// to open topics, CSH calls fail--they only display the Default.htm topic. Using http:// works. Is there a workaround or other solution that would let these customers hostthe Help on a file server and use the file:// method?

[RamonS]

You could use a local HTTP server, there are several that are really compact. That server would only serve the content locally. Of course, you could also use IIS, but that then needs to be installed on the local system and configured.
I searched on Google and picked the first promising hit: http://en.kioskea.net/faq/2568-tinyweb- ... on-windows There are several others, you may need to try a few and pick the one that works the best.

Alternatively, you make the help source configurable. If the application reads the setting that no internet access is allowed (could even run code to automatically check that rather than use a static config setting) then fall back to the 'old' CHM. The content would be the same and with single sourcing aliases and map IDs and such stay the same in either output format.

[sarrants]

Thanks, RamonS. We're trying to avoid HTTP, but may have to go that route if FILE won't /can't work.

[NorthEast]

WebHelp CSH links using file:// work fine for me - both when the WebHelp is on a local drive or a network folder.

How are you testing these CSH calls?

[sarrants]

The developer I'm working with says:

I just open the default browser with the file location. It works if I explicitly type it into the open browser’s window – not if I pass it to the open browser call.

[NorthEast]

I think the issue is how the developer is opening the browser and passing the URL. Maybe the technique being used is only passing the filename and not the # parameter from the URL?
Anyway, it's definitely possible, as our applications use local WebHelp and make CSH calls.

I can also create a html file with a file:// link, and that works fine; e.g.

Code: Select all

<a href="file://C:/MyHelp/Default_CSH.htm#helpid" target="_blank">Link</a>

[sarrants]

Here is the code he is using within the development environment of the application:

Code: Select all

iRet = (int) ShellExecute(NULL, "open", "file:///C:/DevProjects/NL11-NEWHELP/Default.htm#cshid=IDH_AUTO_OBJ_DETECT", NULL, NULL, SW_SHOWNORMAL);

What happens is that Help opens to the Default.htm page, not the context-sensitive target page. But if you paste the

Code: Select all

file:///C:/DevProjects/NL11-NEWHELP/Default.htm#cshid=IDH_AUTO_OBJ_DETECT

into the address bar, you get to the correct page.

[NorthEast]

I'm not sure how our developers implemented it, so I don't know if that's the correct method or not.

I would check that the full URL is actually being passed to the browser.
That may only be expecting a filename, and be dropping the '#cshid=...' part.

[sarrants]

Thanks for the speedy help, everyone!

The PM has decided we will host the Help. The two customers who do not allow outside internet access will serve the help from internal servers.

[Psider]

Just wondering if this change (to match Dave Lee's example) would fix it?

iRet = (int) ShellExecute(NULL, "open", "file:///C:/DevProjects/NL11-NEWHELP/Default_csh.htm#cshid=IDH_AUTO_OBJ_DETECT", NULL, NULL, SW_SHOWNORMAL);

[RamonS]

Yea, needs to be the csh file because that contains the scripts to load the correct content. That is an easy change and worth a try.