Danni,
In some ways, it makes sense to auto-download a .chm to the
user's PC. As Peter points out, HTML help works better on a local
PC. When you updated the .chm on the network, did the new one get
downloaded to overwrite the old one? That would be a nifty way
around the main drawback: Help files on the user's PC can become
obsolete pretty fast.
If your developer is downloading WebHelp files to the user's
PC just because that's how they did it before, he should know he is
making several mistakes:
1. If you don't download the entire WebHelp package every
time, the user's files soon become stale.
2. Then there's the volume of traffic across the network.
Probably the management would not like to put such stress on
bandwidth resources.
3. WebHelp files, as you have found, work on the local PC,
but with some annoying glitches.
4. (This is related to No. 2) With WebHelp on the network,
the user takes up minimal resources to download a topic, even a big
one, with graphics. The developer is passing up a really
significant opportunity for actually lowering traffic volume on a
day-to-day basis. You should feel fairly strong in having this
point on your side.
Maybe there's some overriding requirement to forbid user
access to help files on the server. I'd like to hear it. They're
already using a more powerful application there, right?
An early client of ours worried that if a user can roam
around the help topics unfettered, she might be able to access
parts of the application where she should not go. The client
thought we should limit access to topics according to the
application's privileges structure. Of course, we know you can't
build -- or it would be extremely difficult to program, and
probably would bump into the application's security -- a back door
into the app from a help topic.
Harvey