[Lazarus] installing chm help

Hans-Peter Diettrich DrDiettrich1 at aol.com
Thu Feb 16 18:14:08 CET 2012


Michael Schnell schrieb:

> The current discussion shows that the external interface is not good 
> enough, as it only provides a single word and not the context.

Who says that this "word" cannot be e.g. "#lcl.controls.TButton.Visible"?

> If e.g. the cursor is on "Visible"  in the line "Button1.Visible := 
> True", it can't know that help on TButton in to be shown.
> 
> So the IDE needs to find that Button1 is a TButton and should provide 
> "TButton.Visible" to the help Viewer through the Help package interface.

It's not the IDE, it's the Editor that has to determine the context. If 
it finds an identfier (Visible), it must invoke help for its 
declaration. If it finds a reserved word, it must invoke the language 
reference database instead. For help on a control in an dialog the 
designer of the dialog is responsible, by adding the proper "word" 
(search path) to the control's HelpKeyword or HelpContext.

> If it does not find the type of Button1 it of course just provides 
> Visible to have the help viewer show a selection of possibilities.

This approach is too dumb. FPDoc already does an good job in linking to 
inherited classes or methods, so that a help viewer has all information 
for narrowing down the request to the closest existing help entry. 
Likewise help on a dialog control should defer to the help on the entire 
dialog, when no specific entry is found for help on a contained control.


I only found one situation, so far, where help on e.g. "integer" leads 
to multiple units. This might be improved in the Editor, which IMO can 
*know* whether the current unit uses "objpas" or only "system". Here the 
Editor has better chances, to figure out the precise unit, than the user 
has.

DoDi





More information about the Lazarus mailing list