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.
Subject:Re: WINHELP: DAT files with HLP delivery From:"Cramer, Kim" <Kcramer -at- NCSLINK -dot- COM> Date:Thu, 11 Jun 1998 08:56:29 -0700
> From: John Cornellier[SMTP:cornelli -at- CLAMART -dot- SRPC -dot- SLB -dot- COM]
>
> I'm working on a software product developed in C++. The Winhelp 4.0
> help system for the prog will be delivered with HLP files, CNT files,
> and DAT files. The DAT file contains entries that look like this:
>
> [SomeField]
> foobish.hlp
> 10
>
> Where the 1st line an object name in the UI, and other two lines are
> the hlp file and help context ID. When the user puts the cursor in
> SomeField and hits F1, the prog goes to the dat file, gets the context
> ID, then displays the corresponding topic in foobish.hlp.
>
> Has anyone ever worked with something like this? What is the purpose
> of it?
>
We work with a similar way of linking context sensitive help. Instead
of the context/map ID being added directly to the code for each field,
we use a database table with the IDs and associated Help files.
Our software provides F1 help at the screen level instead of at the
field level. I generate a new database table on our development build
system at the end of our release cycle. It contains records for all
screens and reports in the system, including any new ones. I then take
printouts of the map files for all of the my Help systems and cross
reference the map IDs. Finally I update the table using Access and
submit it back to build. When a user presses F1 in the delivered
software, the program looks up the open screen or report in the database
table to find the correct map ID and the Help system it's part of, then
it displays the proper topic.
This process has been a real pain for me up to now as I was using
Doc-To-Help. D2H assigns new map IDs each time you convert your doc
files to Help files and compile, which causes the majority of them to
change for each release. This meant I had to modify the majority of the
IDs in the database table each time we sent out new code. I've now
changed to RoboHelp, which doesn't change existing IDs. I've also
developed a process in Access (with the help of a friend skilled in
Access) to import the data from the previous version of the table, so
all I have to do is add the IDs and Help files for the new screens and
reports. This is has simplified the process immensely!
HTH
*******************
Kim Cramer mailto:kcramer -at- ncslink -dot- com
Sr. Information Developer
NCS Education, Mesa AZ
*******************
