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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
