Network CHM files

[RPF12]

I have an application that can be installed to a network drive and then used from multiple workstations. Windows/Vista security now makes it difficult to just install the app and use the CHM help files from the server. I do not want the help to live on local machines and it is not feasable to store the help on a webserver since not all workstations may have web access. If there are any suggestions of how to be solve this problem, they would be much appreciated.
Note that this is a old legacy app that has happily used HLP files from the network for many years. I just migrated all of the HLP files to CHM but I am still at square one it seems...

Thanks for any ideas or suggestions.

[Peter Grainge]

Welcome to the forum.

There's a topic on my site that explains what you need to do. However, please note that it involves registry changes that your clients may not be happy about. That is something for you to resolve first.

With RoboHelp 6, webhelp can be made to run from a local PC as well as a server. An option you might want to consider.

[Captiv8r]

Hi all

Note further that WebHelp doesn't require a web server. You can usually run it off a normal network server with no issues.

Just a thought... Rick

[Guest]

Peter,

I know I'm not exactly staying with the topic, but tell me more about your comment...

With RoboHelp 6, webhelp can be made to run from a local PC as well as a server.

We have been using X5 to create context-sensitive WebHelp for Web-based applications. We deploy our WebHelp projects to a RoboHelp server. Users can view the WebHelp by clicking a link in the application.

Now, we need to create context-sensitive Help for some new windows-based applications that are "pushed" to the user's PC. We thought our only option was to create HTML Help (a .chm file), which is included in the "push."

Does your comment mean that, with RoboHelp 6, we could use the RoboHelp server for the windows-based applications?

Thanks for your help,
Liz

[Peter Grainge]

WebHelp sits on a server and can be accessed from there by the application.

By pushed, do you mean installed? If the user nonetheless will always have access to the server to obtain the help, then is that an option.

If not, you can either install a CHM locally or now you can install the webhelp locally. Previously running webhelp locally brought up a yellow information bar unless various IE settings were changed. Not really what you wanted for an end user. Now you can create the webhelp with the Mark of the Web added and it will run locally. I believe links to PDFs may not work so check that out if relevant.

I am guessing that for your developers, it means they only have to change the path to the help so it could be quite a saving. Otherwise the calls to a CHM topic would be different.

[Guest]

Peter,

Yes, by "pushed" I mean installed. I generate an updated CHM file that they include in the deployments. After the installation, the developers update the windows-based application through automatic deployments.

We have other web-based applications that use WebHelp that is called from a RoboHelp server. It would be nice to be able to call the Help for the windows-based application in the same way.

One more question...Do we need RoboHelp Server 6 or just RoboHelp 6 to install WebHelp locally?

Liz

[Peter Grainge]

RoboHelp Server 6 is just for WebHelp Pro installed on a server so your "ordinary" RoboHelp 6 is all you need.

Duplicate your existing webhelp layout and then tick the Mark of the Web in that.

That will give you two identical outputs but where one will run locally. Don't lose sight of the warning re links to PDFs. Do check they work.

[Guest]

Peter,

Thanks for your reminder about checking the links to PDFs. I don't believe we have any, but I will certainly check with the other writers.

Your response was a great help to me.
Liz

[Captiv8r]

Hi Liz

The warning should apply to ANY file type you may be linking to. It's not just the .PDF file type, but Word .DOC, Excel .XLS and others. Actually, I don't believe it matters which file type. Moreover, it's related to the fact that the way you are linking is blocked, as it could be a security risk. The MOTW places the content in a "safe" zone. As such, these types of links are affected. Normal page links are fine, but linking to files becomes "Right out".

Cheers... Rick