Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-02

Feature Request: a new macro for a complete identifier name

8 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

Based on the discussion about offline help viewers, and interesting point was raised. In the case of DocView (which is setup via the External Tools), I use the ${CurToken} macro to allow docview to do a search - based on where the cursor is positioned.

Now somebody brought up a interesting commend. If the cursor was over an identifier "Visible", to which class does that related. Docview does display the search result in a easy manner, so it shouldn't be too hard to use as-is, but it can be improved.

If I put the mouse cursor over "Visible", it will show me something like

property TButton.Visible

So can somebody that knows how, implement a new ${CurIdentifier} macro which can be used in the External Tools entries. So when I press F1 while the cursor is on "Visible", it will actually pass "TButton.Visible" or "TCombobox.Visible" etc to docview.

Lazarus IDE has all the information because the tooltips display all than information, so for somebody that is in the know, they should find it easy to implement such a new macro, by using similar code as is used in the tooltips. I presume it uses CodeTools.

I don't believe it is needed to add (like in fpdoc) the package and unit name to this identifier (eg: #lcl.buttons.TBitBtn.Visible), but if the person that (maybe) implements this feature request thinks it could be useful, then another separate macro should be added for that.

Regards, ? - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net

Reply by email

Sven Barth
to Graeme Geldenhuys
Graeme Geldenhuys wrote 33 lines
Hi, Based on the discussion about offline help viewers, and interesting point was raised. In the case of DocView (which is setup via the External Tools), I use the ${CurToken} macro to allow docview to do a search - based on where the cursor is positioned. Now somebody brought up a interesting commend. If the cursor was over an identifier "Visible", to which class does that related. Docview does display the search result in a easy manner, so it shouldn't be too hard to use as-is, but it can be improved. If I put the mouse cursor over "Visible", it will show me something like property TButton.Visible So can somebody that knows how, implement a new ${CurIdentifier} macro which can be used in the External Tools entries. So when I press F1 while the cursor is on "Visible", it will actually pass "TButton.Visible" or "TCombobox.Visible" etc to docview. Lazarus IDE has all the information because the tooltips display all than information, so for somebody that is in the know, they should find it easy to implement such a new macro, by using similar code as is used in the tooltips. I presume it uses CodeTools. I don't believe it is needed to add (like in fpdoc) the package and unit name to this identifier (eg: #lcl.buttons.TBitBtn.Visible), but if the person that (maybe) implements this feature request thinks it could be useful, then another separate macro should be added for that.

Maybe you should report this on the bug tracker?

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Michael Schnell
Michael Schnell wrote
Of course extending the external tool interface is a rather decent alternative to using the "help package" interface.

The extended macros I suggested could also be used for LHelp - with that I assume LHelp can take command line parameters. That way, all "IDE searching for help" is offloaded to the help viewer - which in my opinion seems the more logical route.

Regards, ? - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net

Reply by email

Marco van de Voort
to Graeme Geldenhuys

In our previous episode, Graeme Geldenhuys said:

Show quoted text 7 lines
> Of course extending the external tool interface is a rather decent > alternative to using the "help package" interface. The extended macros I suggested could also be used for LHelp - with that I assume LHelp can take command line parameters. That way, all "IDE searching for help" is offloaded to the help viewer - which in my opinion seems the more logical route.

Personally I don't like this. It almost forces one to use lhelp, and I would like to keep the option to use CHM via the native windows support.

Reply by email

Michael Schnell
to Marco van de Voort
Marco van de Voort wrote
Personally I don't like this. It almost forces one to use lhelp, and I would like to keep the option to use CHM via the native windows support.

??? (AFAIU) The CHM help is installed as a package, while Graeme's suggestion targets the External Tool interface (which I in fact don't like, but if Graeme decides to go that way I'll be happy, too).

So this is completely unrelated.

-Michael

Reply by email

Graeme Geldenhuys
to Michael Schnell
Michael Schnell wrote
??? (AFAIU) The CHM help is installed as a package, while Graeme's suggestion targets the External Tool interface

Correct.

And if somebody doesn't like the LHelp IDE Integration for some or other reason, they could even setup LHelp via the External Tools, like I have done with DocView. But this is totally optional.

The best of both worlds as far as I can see.

Regards, ? - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net

Reply by email