Programming Help

Programming Help

The final way of characterizing Help, and perhaps the most important to a developer, is
by examining the code behind the scenes. Three Windows messages are sent when the user
invokes Help:
l WM_COMMAND
l WM_HELP
l WM_CONTEXTMENU
NOTE: Windows messages are discussed in Chapter 3, "Messages and
Commands."
When the user chooses a Help item from a menu or clicks the Help button on a dialog
box, the system sends a WM_COMMAND message, as always. To display the associated
Help, you catch these messages and call the WinHelp system.

When the user right-clicks an element of your application, a WM_CONTEXTMENU
message is sent. You catch the message and build a shortcut menu on the spot. Because in
most cases you will want a shortcut menu with only one item on it, What's This?, you
can use a prebuilt menu with only that item and delegate the display of that menu to
the Help system - more on this later in the "Programming for Context Help" section.
When the user opens Help in any other way, the framework handles most of it. You don't
catch the message that puts the application into What's This? mode, you don't change
the cursor, and you don't deal with clicks while in that mode. You catch a WM_HELP
message that identifies the control, dialog box, or menu for which Help is required, and
you provide that Help. Whether the user pressed F1 or went into What's This? mode and
clicked the item does not matter. In fact, you can't tell from within your application.
The WM_HELP and WM_CONTEXTMENU messages are handled almost identically, so
from the point of view of the developer, there are two kinds of help. We'll call these
command help and context help. Each is discussed later in this chapter in the "Programming
for Command Help" and "Programming for Context Help" sections, but keep in mind that
there is no relationship between this split (between command and context help) and the
split between one-step and two-step Help that users think of.