Bad default HtmlHelpCompilerFilename

Logged In: YES
user_id=87620

Good idea. How about if we default to the value of
System.Environment.SpecialFolder.ProgramFiles + "\HTML
Help Workshop\hhc.exe"?

Logged In: YES
user_id=87620

Hmm. It looks like we already default get the ProgramFiles
special folder and then append to that. Is it possible
that ProgramFiles on your system is still set
to "C:\Program Files" even though your %SystemDrive% is
not "C:"?

Our example projects probably have the
HtmlHelpCompilerFilename set using "C:". But that's
because we saved those projects on one of our machines
where our system drive is "C:". If you create a new
project from scratch would it default to whatever your
system drive is?

Logged In: YES
user_id=235364

The problem would lok better if we use the %ProgeamFiles%
environment variable in the default path.

Logged In: YES
user_id=235364

Default path set to %ProgramFiles%\HTML
Help Workshop\hhc.exe, and expanding the environment
variables.

Now what if the user has installed the html help compiler
in a different path?

Logged In: YES
user_id=87620

Isn't this the same thing it was doing before with the
GetFolderPath function?

Does the HTML Help Compiler put anything in the registry
when it gets installed? I just found a possibly useful
value here HKEY_CURRENT_USER\Software\Microsoft\HTML Help
Workshop called InstallDir. Do you think we could rely on
this being set and display a message to the user if it
doesn't exist?

Logged In: YES
user_id=235364

The advantage of using an environment variable is that you
can use the same project file on computers that have
different %ProgramFiles% paths.

Now if we get the hhc install directory from the registry,
it even better. :-)

Logged In: YES
user_id=235364

I checked on a couple of machines here and I did not find
the InstallDir value in the registry, so I guess we can't
rely on that... I'll work on another approach.

Logged In: YES
user_id=87620

Did you install the HTML Help Workshop separately? I did
so that might be way I have that registry key. Maybe it
doesn't install that key if you get the Workshop with
VS.NET.

I have some associations that reference files in that
directory. Here's one:

HKEY_CLASSES_ROOT\Applications\hhw.exe\shell\open\command

There's a bunch of COM objects that have been registered
in that directory, too:

HKEY_CLASSES_ROOT\CLSID\{4662DAA2-D393-11D0-9A56-
00C04FB68BF7}\InprocServer32

I don't know what this key is but it looks promising:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersio
n\App Paths\hhw.exe

I found these by searching for "HTML Help Workshop".

Logged In: YES
user_id=235364

The only registry key with hhc.exe's path that was present
on all my workstations is:

HKEY_CLASSES_ROOT\hhc.file\DefaultIcon

So now, if the MSDN documenter does not find hhc.exe in
the default location, it tries the path from that registry
key's default value.

If both methods fail, the documenter throws an exception.

I think we should try this for a while, as I think it is
better than having the hhc.exe path written in the project
file.

Logged In: YES
user_id=235364

No one has complained yet, so I'm closing that bug.