Context Sensitive Help for tachart component

[chucky]

I dont understand why the tachart package is not included in  context sensitive help. I compiled a tachart.chm file and moved it into the docs directory but I cant figure out how to enable the IDE to use it. I can open it up manually but it would be nice if I could place the cursor on a tachart method or property and hit F1.

Can anyone point me in the right direction or help me understand what I need to do?

Cheers!

[dsiders]

I dont understand why the tachart package is not included in  context sensitive help. I compiled a tachart.chm file and moved it into the docs directory but I cant figure out how to enable the IDE to use it. I can open it up manually but it would be nice if I could place the cursor on a tachart method or property and hit F1.

Can anyone point me in the right direction or help me understand what I need to do?

Cheers!

The only mechanism I've found for anything other RTL, FCL, LCL, and LazUtils help files is the externhelp package located in $(LazarusDir)/components/externhelp. It has to be installed in the IDE (which it is by default), and you must use Tools > Options > Help > External to create a help database registration for your help file. For instance, I created an entry for a CHM file for lazcontrols as pictured in the attachments.

Enter the Name, Unit File or Directory, and URL to the values you need for your help file. After making and applying the change, you'll be prompted to rebuild the package and the IDE.

At that point, F1 should open the application associated with CHM files on your system using the file name and the selected identifier in the IDE.

I'm on Linux, but I don't think Lazarus cares about the path delimiter used. It'll accept both \ and /.

Good luck.

[marcov]

Interesting, I didn't know that that worked!

Pity though that it uses paths to find topics, rather than work via de CHM index system.

[dsiders]

Interesting, I didn't know that that worked!

Pity though that it uses paths to find topics, rather than work via de CHM index system.

On the plus side, it doesn't require modifications to any code in the IDE help manager.
Or adding hard-coded stuff in chmhelp.
Just a setting and a package rebuild.

I would really like it if any installed package could register its CHM or HTML help from a setting in the .lpk file when the package is built.
I tried to implement this (several times)... and failed on every attempt.
The integrated IDE help is a Rube Goldberg machine that I have never fully understood (yet).

[marcov]

Interesting, I didn't know that that worked!

Pity though that it uses paths to find topics, rather than work via de CHM index system.

On the plus side, it doesn't require modifications to any code in the IDE help manager.

But it does in the CHM generator.  I think this is fine for context sensitive help (where the help path is in the control), but not for editor lookup.

Or adding hard-coded stuff in chmhelp.

Could be a base class for editor help that chmhelp could override.

I would really like it if any installed package could register its CHM or HTML help from a setting in the .lpk file when the package is built.
I tried to implement this (several times)... and failed on every attempt.
The integrated IDE help is a Rube Goldberg machine that I have never fully understood (yet).

Yes it is murky. And the Textmode IDE (which CAN do this btw) is also not really transparent. It wants to assign everything a 16-bit topic ID, and you have to build a database with all topics to be able to do that.

[dsiders]

On the plus side, it doesn't require modifications to any code in the IDE help manager.

But it does in the CHM generator.  I think this is fine for context sensitive help (where the help path is in the control), but not for editor lookup.

Well that's strange, because my example works fine in the IDE source editor.

Or adding hard-coded stuff in chmhelp.

Could be a base class for editor help that chmhelp could override.

Then there's all those THelpDatabase instances sprinkled generously through multiple areas.

I would really like it if any installed package could register its CHM or HTML help from a setting in the .lpk file when the package is built.
I tried to implement this (several times)... and failed on every attempt.
The integrated IDE help is a Rube Goldberg machine that I have never fully understood (yet).

Yes it is murky. And the Textmode IDE (which CAN do this btw) is also not really transparent. It wants to assign everything a 16-bit topic ID, and you have to build a database with all topics to be able to do that.

My idea was to populate the HelpDatabases at IDE start-up using the IDE help setting options.
But that doesn't account for the FPC help files where these is no .lpk installed in the IDE - or does not have an .lpk file at all (like Keywords, LangRef, and such).
This is where I always fall down.

Some day...

[marcov]

But it does in the CHM generator.  I think this is fine for context sensitive help (where the help path is in the control), but not for editor lookup.

Well that's strange, because my example works fine in the IDE source editor.

I meant the fact that you have to specify the URL layout. That assumes current fpdoc used to generate the CHM, which is a unnecessary limitation.

Could be a base class for editor help that chmhelp could override.

Then there's all those THelpDatabase instances sprinkled generously through multiple areas.

I'm now talking about types. One for html that searches using paths, one for CHM that searches uses index (and thus is not bound to fpdoc layout)

Yes it is murky. And the Textmode IDE (which CAN do this btw) is also not really transparent. It wants to assign everything a 16-bit topic ID, and you have to build a database with all topics to be able to do that.

To be clear, I meant that the textmode IDE can add arbitrary CHMs that not depend on fpdoc specific path layout.

My idea was to populate the HelpDatabases at IDE start-up using the IDE help setting options.
But that doesn't account for the FPC help files where these is no .lpk installed in the IDE - or does not have an .lpk file at all (like Keywords, LangRef, and such).
This is where I always fall down.

Some day...

Those will always be special. It is the one size fits all that is the problem IMHO.  You can be /too/ generic.