Please read the DISCLAIMER before you use any of the tips from this web site. Go to main index

Tip 5:  Avoid hard coding context numbers!

(modified: 26 Jan 2004)

Tip 8:  HelpHikes Pro, Generating context ids in Object Pascal for Delphi

(modified: 26 Jan 2004)

Tip 3:  Setting help file in Project Options is not enough!

(modified: 19 Mar 2001)

Tip 4:  Opening a help topic directly

(modified: 19 Mar 2001)

Tip 6:  For advanced requirements, call WinHelp directly instead of wasting time looking for a solution in the IDE.

(modified: 19 Mar 2001)

Tip 7:  How to pop up the Help Topics dialog?

(modified: 19 Mar 2001)

Tip 9:  Alternate solution to let Windows find your help file

(modified: 19 Mar 2001)

Date added/modified: 26 Jan 2004

You might be tempted to directly enter the help context numbers in the Object Inspector and in your code. But, don't do it! If your help file grows, as most often they do, the context numbers for the topics are likely to be changed. Of course, you can take steps to prevent this, but hard coding numbers in any programming is a bad idea. You should use constant definitions. To make it easier, if your help authoring tool generates the definitions for you, it would be great! My tool HelpHikes Pro does.

Suppose, you get the constants defined in a file called helpids.pas. You can then include it in any source which wants to use it. Including it in the main source's interface might be a good idea.

Once the constants are available to you, all you need to do is set the help context numbers in the HelpContext properties of your components in the FormCreate of a form. You just code it once. If your help file grows extensively in the next version, just a recompilation of your Delphi project will take care of ensuring that your help calls don't break even if the context numbers changed for those topics. My Application Models freeware shows this sample code.

If, instead, you prefer using the numbers directly in Object Inspector, you should make sure that your help authoring tool has features to assign a fixed context number to a topic which never changes. My tool HelpHikes Pro does.

Date added/modified: 26 Jan 2004

If you are using my help authoring tool HelpHikes Pro, you would already know that it generates the context IDs for help topics in C in a file with the extension INC. To generate an additional constants file in Object Pascal, you need to add a template topic to your folder. Just look up the HelpHikes help file index for Delphi and you will get the details.

Date added/modified: 19 Mar 2001

If you think just setting the help file name in the Project options is enough, try this test. If your application has an open file dialog, use it and change the current directory. Then, close the dialog and try your Help menu. You will get a strange error that help file is not found. I have seen many applications fail this way when providing help. To avoid this problem, set the help file name in your FormCreate and put a complete path instead of just the file name.

Application.helpFile := ExtractFilePath(Application.ExeName) + PrmHelpFileName;

My Application Models freeware contains this and other sample code related to help integration.

Date added/modified: 19 Mar 2001

If you set the helpContext numbers for your forms, menus and components properly, pressing F1 should bring up the help on them without any problem. But, what if you want to show a particular help topic when a button is pressed? Then you need to call the help directly in the click event for the button. There are many ways to get to the topic but the simplest is by help context. Here is an example:

  Application.HelpContext(IDH_INTRODUCTION);

Here, you could have entered the context number for the help topic directly. But, it would be better if your Help Authoring tool generates Pascal constants for you to use. This is explained in another tip.

Date added/modified: 19 Mar 2001

If your requirements are special or advanced, you may have to handle the onHelp event and call WinHelp directly. For example, in the case of my application ShowSize, I decided on the following requirements for my help:

1. I wanted to display some topics in the main window. An example is the help topic invoked from the button "Ordering information."
2. To conform to the Windows 95 style, I wanted most of my context sensitive help to appear in a secondary window called procwin.
3. I didn't want to write any help for the most obvious menu items like "File--Exit" or "Help--Help Topics."

After much tweaking, I found that there was no point using the default processing here. I tried all combinations, and it didn't work. Hence, I decided to call WinHelp directly for many cases and made utility functions of my own that use secondary windows if needed. To show the solution, I have created a complete sample application in a product, Application Models freeware.

Date added/modified: 19 Mar 2001

I have seen many users ask on the usenet, how to pop up the Help Topics dialog. It's simple:

  Application.HelpCommand(HELP_FINDER, 0);

The above will work, provided you have set the helpfile property of the application. However, you should do that in code. Why? See the tip "Setting the help file name in project options is not enough!"

Date added/modified: 19 Mar 2001

Martin Liesén sent this alternate solution to the problem of finding the help file, mentioned in the tip "Setting help file in Project Options is not enough!" You may avoid adding full path of the help file in the code if your installation program takes care to register your help file in the windows registry:

The registry key: HKEY_LOCAL_MACHINE/Software/Microsoft/ Windows/Help
Entry: 'MYHELP.HLP' with the value of your path name 'C:\MYPATH'

If you do this, Windows will be able to find the help file even if your current directory changes. Thanks to Martin for sending this tip!

Note: Of course, this only solves the problem of finding the help file, mentioned in the first tip, not the advanced usage requirements. Besides, if the user happens to move your program to another directory or computer, it will stop working. You might assume that the users always use installation programs to move stuff around. But, in all my support experience, I have seen users do all kinds of stuff, like straight copying of program files to another directory. Then, they wonder why it doesn't work! If you want to reduce the support costs, you need to put code in the program which you normally would put in an installation program. It pays in the long run.

Copyright 1995-2004, Sanjay Kanade. All rights reserved.
All trademarks and copyrights belong to their respective owners.