What is happening is that F1 gets special treatment by the system. Yes it is true that your menu item's handler that has a shortcut of F1 fires. But after that handler has fired, the app receives a WM_HELP
message.
This WM_HELP
message is processed initially by TCustomForm.WMHelp
. This looks up the help context ID associated with the active control. And then Application.HelpContext
is called using that help context. And presumably the active control's help context ID differs from that of the form.
So, although your menu item opens the help file at your preferred topic, the subsequent WM_HELP
overrides the menu item.
It appears that you want all F1 always to route to the form's help context ID. In which case, my advice would be as follows:
- Set the
HelpContext
for the form. - Remove all
HelpContext
properties for all other controls on your form. In other words, revert them to the default value of0
.
Then when the WM_HELP
message is handled, it starts at the active control and find a help context of 0
. Then it will rise up through the parents to the form, which is non-zero.
I think that I would also remove the F1 shortcut from the menu item / action. And let the WM_HELP
message be the mechanism for invoking help.