TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Does your boss mean "link to our help file", or "replace ours with theirs"?
You deal here mostly with the second case. And no, there's no problem with
the registry or anywhere else just copying over xxxx.hlp. We do it all the
time. There is, however, a problem with the .cnt if you do that. The .cnt
actually has links to specific IDs in the .hlp, and without the .hlp file
that it was created with, the .cnt won't work. You can replace both and be
just fine. The system does not reference the registry for a help file; it
just uses calling code from within the application. That code can use either
absolute or relative addressing.
The other option is a bit more complex. I have no idea how you'd do such a
thing with RH. I don't use it (thankfully). Using ForeHelp, I would first
urge the client to give me his RTF, whereupon I'd compile it with mine in a
matter of a few minutes.
If your app uses context sensitivity, you probably can't just drop the
client's RTF in, unless you replace yours with his, and they map one-to-one.
Otherwise, the user will have to dig around in a TOC to find the
information. Kludgy, but perhaps acceptable.
There is another possibility. If you give your files to the client, he can
add whatever he pleases. He doesn't need RH files...an RTF with the .hpj
will do and graphics. Then he can just overwrite the standard files with his
own. Of course, there would be no context sensitive links to his added
topics, because you need source code to add those.
Yet another possibility is to supply your compiled .hlp, but include both
his and yours in the .cnt. One .cnt can open more than one .hlp. This would
require that he supply you with his help source file, or the other way
around, so one of you can compile a single .cnt.
Altogether, I'd recommend just supplying the client with your source files.
Let him tinker if he wants. He can't do much damage so long as he doesn't
blow out the target topics called from the app.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
----- Original Message -----
From: Paul Hanson <PHanson -at- Quintrex -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Cc: 'Tech Writers List' <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Wednesday, August 09, 2000 2:33 PM
Subject: Customizing Help [LONG]
> CROSS POSTED ALL OVER! <shoutin' and grinnin'>
> Okay. Here we go. The president of the company just swung by and asked
> the following. If our clients get RoboHELP, and write their own
> procedures, is there a way to get each client's .hlp file linked into
> ours?
>