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.
Damien - Attached are two responses to your problem from a friend of mine
who's a kind of techno-guru. I've arranged them with your help requests
first, his answers second. If they are helpful, please let him know. -
Marilyn Baldwin (mlbb -at- capgroup -dot- com)
---------------------- Forwarded by Marilyn Baldwin/CDS/CG/CAPITAL on
05/27/98 11:11 AM ---------------------------
From: Damien Braniff
Subject: Help file/NT Problem
Hello everybody, back from the long Bank Holiday weekend to a problem I
hope you can help with.
I have a help file which is called from is a 16-bit application so I've
compiled it with V4 compiler and 16 bit DLLs selected - worked fine on my
machine when I tested before the weekend. Still fine on my PC (Win 95) but
getting a variety (well 2!) of errors on NT. The first (HDK3CT16.DLL)
missing is my fault and easily fixed (HDK is the HAT I'm using). The other
is more perplexing - the error message (when called from the application)
is that the file called isn't a recognised help file. However, when you
simply double click on the file from Explorer you get a message (using V3
compiler etc) and it opens fine! I've tried several different compile
options to get it to work on NT but to no avail - I even got a message once
that a newer version of the Help was needed to read the file!
I've tried a clean install on a Win 95 PC and it works fine.
From: "Sargent; Mark" <Mark -dot- Sargent -at- transamerica -dot- com>
Subject: Re: Help file/NT Problem
ANY TIME you get the message "A later version of Help is needed to read
this file", it means the program which is loading the help file- some
version of WinHelp, loaded by some application-- is an older version versus
the version of the help file (.HLP) you're using. In the situation he
presented, the application is calling the wrong version of WinHelp
(probably because it brought its own version with it), and it can't read
the file he generated with a later version of HC. Find out why the
application is calling the wrong version of WinHelp.
A word of warning: for all but the most highly trained and experienced
user, REGEDIT should not be used except in Read-Only Mode (the old kind of
Read-Only where you don't save anything). That is, use REGEDIT/REGEDT32
only to determine Registry content, not to make changes, or you may
discover what Windows 95 looks like when it only comes up in DOS mode.
This is not a put-down intended for a help developer (Microsoft has made
that a thoroughly miserable job through positively criminal neglect of the
process: the HC is the most user-hostile piece of slime in the world), but
the skillset needed to futz with the Registry is very different from the
skillset needed to produce a good help file.
In any case, learn how to backup the stupid thing (see the article below:
you should back-up your registry after making any hardware or major
software changes) before you make ANY changes. Trust me: the thing is
bounced around continuously while Win95 and NT operate and your updates may
end up "crossing" internal updates. Think of how long it would take you to
restore everything on your hard drive before you get gutsy...
+++++++++++++++++++++++++++++++++++
Extract from The Miscorsoft Developer's Network Article on Savbiogn and
Restoring the Registry:
The Registry can be exported, imported, or recreated using either the
Windows-based version of Registry Editor or the real-mode version on the
Windows 95 emergency startup disk. By using the export capabilities of
Registry Editor, a specific branch or the entire Registry can be saved in
text format as a .REG file. A branch of or the entire Registry can be
restored by importing a .REG file that was created by exporting the
Registry.
If you are exporting or importing Registry files using the Windows-based
version of Registry Editor, use the Export and Import commands from the
Registry menu. The information in online Help can guide you through this
process.
In rare circumstances when the Registry is badly corrupted, you can start
the computer using the Windows 95 startup disk. Then you can use the
real-mode REGEDIT.EXE utility on the startup disk to import a .REG file. In
this case, the following command syntax can be used at the command prompt.
/L:system Specifies the location of SYSTEM.DAT.
/R:user Specifies the location of USER.DAT.
file1.reg Specifies one or more .REG files to import into the
Registry.
/e file3.reg Specifies the filename to which the Registry should be
exported.
regkey Optionally, specifies the starting Registry key from which
to
export a portion of the Registry. If no value is specified,
regedit /e exports the entire Registry.
/c file2.reg Specifies the .REG file to use to replace the entire
contents
of the Registry.
Caution Use the regedit /c option with extreme care, and only when you
are
sure that the specified .REG file contains a complete image of the
Registry.
Also, the Windows 95 Resource Kit does not provide sufficient information
to guide you through the process of editing an .REG file, so it is
recommended that you undertake editing an .REG file only under the guidance
of your product support representative.
+++++++++++++++++++++++++++++++++++
==================================================
From: Damien Braniff
Subject: NT/Help Problems
I'm baffled. I'm sure the answer is simple (I hope) but I can't see it at
all, nor can development. I'll re-iterate the situation so that,
hopefully, there is no confusion.
The product is the administration software (16 bit) for an access control
system. Help is translated into several languages and the help file is
called global.hlp. The other languages are called global.fre, global.ger
etc. When installed the software checks the language and then access the
relevant help file.
I work on Win95 and the help has been tested both standalone and in
conjunction with the software and it works fine. The problem seems to be
only with NT which is giving the error "Not a valid Help File". I have
tried several compile options - compile V3.1 with 16 bit and generic DLLs,
and V4 with 16 bit DLLs. My initial thought was that the file being
accessed by the program was different from the one I had just compiled but
I've been told this isn't the case. The software looks in a specific file
in the instal folder.
OK, so it doesn't run the file from the application but, if you go to
Explorer and run it from there then it's fine - you get the message that
it's using 16 bit DLLs and will use 3.1 engine but that's what I'd expect.
Any ideas anyone??!!!
==================================================
[_] When you run something from within Explorer/File Manager (or even a
browser), he takes the file type and looks in the Registry (on 3.x, he'd
look in Win.Ini) for the file association: a tuple which gives the file
extension followed by the executable name assigned to handle that
extension. Click on the file name, he strips off the extension, matches
against the registry list, and then launches the appropriate app, handing
it the name of the file as a command-line parameter. Look in
HKEY_CLASSES_ROOT. You'll also notice that a lot of that stuff has a
double- or triple-jump: .XLS will point to Excel.Sheet.5, which has its own
association entry describing how to launch the application, including
(usually) the FULLY QUALIFIED PATH of the executable. The executable could
be on Mars as long as you had a long enough LAN cable [ :-) ]. Maybe
someday it will be, once they perfect faster-than-light telephones...
[_] When you run Winhelp inside a program, the WIndows API launches a
program (not a DLL) and passes it the name of your help file as a
parameter: you don't specify the name, because the Windows API does that
for you.
Wherever that program is first found on the System search path (in a DOS
window, enter the command PATH or SET- if you used SET, look for the line
which starts PATH=) is the place where the Winhelp executable is run from.
One of the problems is, if you are using 16-bit, it automatically specifies
WINHELP.EXE. If you are in 32-bit, it automatically specifies WINHLP32.EXE.
All the application programmer said was
WinHelp("myhlpfil.hlp").
Windows calls the appropriate program depending on whether he's running
32-bit or 16-bit.
See where things are going? Your program is only "appropriate" for a 32-bit
WInHelp, but it's being run by a 16-bit WinHelp API.
If you want to continue in a 16-bit app, you can replace your calls to the
WINHELP API with a WINEXEC for WINHLP32.EXE: this is OK in a 32-bit
environment (WINHLP32 won't run under 16-bit), because WINHLP32 is
launched, as opposed to being used as a DLL (you can't call a 32-bit DLL
from a 16-bit program without having a "thunking"-- 16->32-bit conversion
layer-- in between).
My suggestion is save time and start migrating the application to Win32
soon: it's a good year's worth of work to learn the differences and to
re-learn to debug. You also don't know just how much extra garbage is being
run by doing 16-bit calls in a 32-bit system. There's also the painful part
about the initiation and the knives and the blood... [ :-) ]
