We have found an odd situation. It appears to us as though Help.ShowHelp does not always work, with the two biggest factors being what chm file is called and if a FileDialog has been called before the call to Help.ShowHelp.
As long as a call to Help.ShowHelp is made before completing a FileDialog (OpenFileDialog or SaveFileDialog), it works fine – every time. But if a FileDialog is completed before the first call to Help.ShowHelp, the help call either doesn’t work or at best it shows an incomplete chm file. The results vary depending on the chm file that is called.
We set up an isolated example where a form simply has an “open” button, and then four buttons for help. The open button triggers an OpenFileDialog and the selected file’s name is just assigned to a string. No file processing takes place.
The first help button calls:
Help.ShowHelp(this, “dda_help.chm”); //our compiled help file
The second help button calls:
Help.ShowHelp(this, “wkspf.chm”); //a Microsoft Works help file
The third help button calls:
Help.ShowHelp(this, “msinfo32.chm”); //a Microsoft Windows help file
And the fourth help button calls:
Help.ShowHelp(this, “http://www.microsoft.com”);
Observations:
1) The only help button that always works is the fourth – the web page call.
2) dda_help.chm and wkspf.chm behave identically… they work fine as long as the first call to them is made before successfully completing a FileDialog. If a FileDialog is completed first and then you try to open dda_help.chm or wkspf.chm, the debugger will step right through the Help.ShowHelp line with no errors and nothing happens.
3) msinfo32.chm behaves strangely. It opens regardless of a FileDialog completion, but if the FileDialog is completed before the first call to msinfo32.chm, the chm appears to be corrupt. There is only one entry in the Table of Contents and the default page appears to have changed.
Any info / insight on this How can we get our help file to always come up
Thanks,
Darren

Help.ShowHelp does not always work
Raja_Krish
Simply concatenating Application.StartupPath to the beginning of the chm file fixed it.
Regards,
Darren
xiang.zhiwei
Don
bgs
The catch is if the user double-clicks an associated file to open the program, we have no idea what directory the program will start in. Additionally, if the user changes the install configuration, we may very well not have any idea where the program is installed. How can I detect where the actual program file is (and thus the chm file) at run time
Thanks,
Darren