[Lazarus] Building help files: the nitty-gritty

classic Classic list List threaded Threaded
111 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mark Morgan Lloyd
Reinier Olislagers wrote:

> On 18-7-2012 13:18, Mark Morgan Lloyd wrote:
>> Graeme Geldenhuys wrote:
>>> The following URL is exactly what I am talking about, but as I said,
>>> it only describes HTML help (lots of HTML files located in a folder),
>>> and has limited help abilities.
>>>
>>>    http://wiki.freepascal.org/Add_Help_to_Your_Application
>> As I wrote yesterday, I've added a brief section to that page on
>> generating arbitrary .chm files.
>
> I think you might mean this page?
> http://wiki.freepascal.org/chm_backend_for_fpdoc

I do indeed. And there was I thinking that a certain party never
listened to anything anybody said... :-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Reinier Olislagers
In reply to this post by Michael Schnell
On 18-7-2012 14:04, Michael Schnell wrote:
> On 07/18/2012 01:41 PM, Reinier Olislagers wrote:
>> I'm sorry but it seems so much more constructive to discuss actual
>> ways forward to solve things based on what we have now, even if it is
>> step by step, than to keep talking about abstract concepts.
> While I do see your point, I of course don't agree.
>
> To me it does make sense to decide whether I want to drink tee or beer,
> before opening either the cupboard or the fridge. ;-)

Well... have you decided whether you want to have tea or beer? If so, why?

In other words, if you see another possible architecture/solution,
please share, as I'm sure that will help choose the best one.


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mark Morgan Lloyd
In reply to this post by Graeme Geldenhuys
Graeme Geldenhuys wrote:

> On 18 July 2012 12:18, Mark Morgan Lloyd
> <[hidden email]> wrote:
>>>    http://wiki.freepascal.org/Add_Help_to_Your_Application
>> As I wrote yesterday, I've added a brief section to that page on generating
>> arbitrary .chm files.
>
> Strange, as I see no such amendment.  There is no mention of CHM
> files, and the line at the bottom of the page footer says "This page
> was last modified on 15 April 2012, at 11:44."
>
> Maybe you amended some other wiki page?

As Reinier points out, I was thinking of
http://wiki.freepascal.org/chm_backend_for_fpdoc Mea culpa.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mark Morgan Lloyd
In reply to this post by Michael Schnell
Michael Schnell wrote:
> On 07/18/2012 01:41 PM, Reinier Olislagers wrote:
>> I'm sorry but it seems so much more constructive to discuss actual
>> ways forward to solve things based on what we have now, even if it is
>> step by step, than to keep talking about abstract concepts.
> While I do see your point, I of course don't agree.
>
> To me it does make sense to decide whether I want to drink tee or beer,
> before opening either the cupboard or the fridge. ;-)

But first you have to identify the need: that you're thirsty :-)

I think Reinier and I are saying that the need in the current case is
how to intercept F1 and recover an associated keyword, and how to pass
that keyword to lhelp.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Michael Schnell
In reply to this post by Reinier Olislagers
On 07/18/2012 02:30 PM, Reinier Olislagers wrote:
> Well... have you decided whether you want to have tea or beer? If so,
> why?
Nope.

I just intended to provide a hint so that those that are inclined to do
some work on that behalf might consider this and might be able to do the
decision on an even broader base of information.

> In other words, if you see another possible architecture/solution,
> please share
I think I did exactly this:

My suggestion is, that the help system (displaying and help in a user
application and creating help content) Lazarus offers for it's users
should be the same that the IDE uses to provide help for the application
programmers and that enables Lazarus-contributors to create/update
Lazarus help content.

-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Michael Schnell
In reply to this post by Mark Morgan Lloyd
On 07/18/2012 02:35 PM, Mark Morgan Lloyd wrote:
>
> But first you have to identify the need: that you're thirsty :-)
>
Yep. Seemingly both are: The application programmers that want to
provid3e a help system to their users, and the application programmers
that want to use a help system when working with Lazarus. Moreover those
willing to provide/update content to the Lazarus help system are
thirsty, too.

> I think Reinier and I are saying that the need in the current case is
> how to intercept F1 and recover an associated keyword, and how to pass
> that keyword to lhelp.
Of course you are right. This is one aspect of the functionality that
might be provided by the Lazarus LCL to have the application programmers
provide a "help" functionality to their users. Other aspects of this
functionality is launching a help viewer (or providing an internal one)
and allowing the programmer to create the help files in a decent way.

Beer: _When_ all this is resolved in a perfect way for the IDE, any
application programmer can just use it for his own product.
Tee: some unrelated system might be integrated in the LCL that is usable
for the application programmers' product. Same supposedly will use some
3rd party help writing tool.

-Michael



--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Reinier Olislagers
In reply to this post by Michael Schnell
On 18-7-2012 15:30, Michael Schnell wrote:

> On 07/18/2012 02:30 PM, Reinier Olislagers wrote:
>> Well... have you decided whether you want to have tea or beer? If so,
>> why?
> Nope.
>
> I just intended to provide a hint so that those that are inclined to do
> some work on that behalf might consider this and might be able to do the
> decision on an even broader base of information.
>
>> In other words, if you see another possible architecture/solution,
>> please share
> I think I did exactly this:
>
> My suggestion is, that the help system (displaying and help in a user
> application and creating help content) Lazarus offers for it's users
> should be the same that the IDE uses to provide help for the application
> programmers and that enables Lazarus-contributors to create/update
> Lazarus help content.

I'm sorry. You can't have your cake and eat it.
The high level idea you write above was already posted by e.g. Mark. You
(IIRC later) then wrote the same idea.
Then Mark & I proposed a way to implement it, Graeme did additional
research and I asked for your comments on that, and it turns out you
don't have any.
I still don't see the added value of your posts, and will leave it at that.


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Reinier Olislagers
In reply to this post by Michael Schnell
On 18-7-2012 15:39, Michael Schnell wrote:
> Tee: some unrelated system might be integrated in the LCL that is usable
> for the application programmers' product. Same supposedly will use some
> 3rd party help writing tool.
Sorry, perhaps we're talking at cross-purposes which may explain some of
the confusion.

Your tea option: having another help viewer integrated is *exactly* what
has already been proposed: the IDE<>lhelp communication protocol could
be used for third party help viewers, whatever file format that viewer
wants to use, and whatever tools that can be used to generate that file
format.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Michael Schnell
On 07/18/2012 03:44 PM, Reinier Olislagers wrote:
> Sorry, perhaps we're talking at cross-purposes which may explain some of
> the confusion.
>
> Your tea option: having another help viewer integrated is *exactly* what
> has already been proposed:
I do know.

With my contribution I just wanted to say that I think that this option
should not be put aside just because there are some difficulties
assigned to it (e.g it has been stated that fpdoc is not  perfectly
suited for the task of creating such help content. So my hint was that
in the past there has been suggestions for improvements.

Sorry for being a troll (again).
-Michael

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Graeme Geldenhuys
In reply to this post by Mark Morgan Lloyd
Hi,


> I think Reinier and I are saying that the need in the current case is how to
> intercept F1 and recover an associated keyword, and how to pass that keyword
> to lhelp.

Surely the "capturing of the F1 key press" functionality already
exists in LCL? I also see TControl.HelpType, TControl.HelpContext,
TControl.HelpKeyword and Application.HelpFile properties... Are they
just for show (not functional yet)?

Another problem I spotted was with the Application.HelpCommand()
signature. It's got the signature designed by Borland Delphi v1
(somewhere around then) for the use with the very old WinHelp help
viewer and the long discontinued .HLP files. I've already raised this
issue some years back, but received my usual answer that it will not
be changed - go figure. Anyway, a more sane signature for
Application.HelpCommand() would be like Delphi & Kylix defined it for
the CLX framework. As a matter of fact, the help system for CLX was
designed to be cross-platform and uses Interfaces to be very flexible.
It is probably the cleanest help system design I have ever seen, and
it supports multiple help viewers too. Kylix even came with two
reference implementations - a Man Page viewer and a HyperHelp viewer.

For more interesting discussions on Lazarus help system ideas, see
this message thread from way back in May 2006...

  http://www.mail-archive.com/lazarus@.../msg07364.html


May 2006 was a busy month for talk about help systems and help
formats. If the archives would be easier to view, it would help a lot.
I found some links though, but they don't all start at the beginning
of each message thread.

  http://www.mail-archive.com/lazarus@.../msg07274.html
  http://www.mail-archive.com/lazarus@.../msg07368.html


--
Regards,
  - Graeme -


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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mark Morgan Lloyd
Graeme Geldenhuys wrote:

> Hi,
>
>
>> I think Reinier and I are saying that the need in the current case is how to
>> intercept F1 and recover an associated keyword, and how to pass that keyword
>> to lhelp.
>
> Surely the "capturing of the F1 key press" functionality already
> exists in LCL? I also see TControl.HelpType, TControl.HelpContext,
> TControl.HelpKeyword and Application.HelpFile properties... Are they
> just for show (not functional yet)?

Of course they work- in the context of the HTML help components. But if
you'd been paying attention you'd have seen that what Reinier raised was
how to use lhelp's (socket?) interface to get it to display a named
page, and that's not very much use unless you can get the appropriate
keyword to the other end of the communication connection (i.e. get F1 to
behave properly).

Now I presume that the existing HTML help components tell the LCL that
they want F1 when they auto-register, but in the absence of comparable
components for CHM we need to know how to do it.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Graeme Geldenhuys
In reply to this post by Graeme Geldenhuys
Hi,

On 18 July 2012 16:10, Marco van de Voort <[hidden email]> wrote:
> Basically the source for a CHM is
>
> a .hhp file, which is an ini-like format containing
> 1. references to which are the toplevel html files to link
> ....snip....

Thanks, those steps were really helpful. That gave me a good starting
point, and I'll Google .hhp files further.


> I don't think an application call makes sense at all. It should be IPC
> (dbus) like,
> to avoid multiple instances, and to avoid having settings at all.

I agree with this.  fpGUI currently uses TProcess to start up DocView,
but that was just step 1 to get the help system going. I'm working on
step 2 now, which is the IPC communications.


> IOW an IPC call to register helpfiles at startup (and start a small daemon
> if necessary), and then just fire the
> "show help" or "give me index" commands.

Yes, that is how I understood it too. The dbugintf.pas unit and the
various "debug server" apps around are good working examples of this.


>> specific help topics.  The fpgApplication instance has a HelpFile
>> property to specify where an applications specific INF help file is,
>
> (Only one helpfile per app?)

No, you can concatenate multiple help files, specify a help directory
(instead of a file), specify an environment variable etc... DocView is
very flexible with this.


> I don't ship Lazarus applications.

:-/   Time to speak to your boss then.


> At work I use Delphi, but I don't ship help with those either.  (though I
> have in previous jobs).  We ship latex generated manuals in PDF format for

You guys have it way to easy! :)  All our apps must ship with help
files, and we have a separate installation PDF. Our end-users are not
the most computer literate, but they know everything about Maths and
Science.



--
Regards,
  - Graeme -


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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mark Morgan Lloyd
Graeme Geldenhuys wrote:

>> At work I use Delphi, but I don't ship help with those either.  (though I
>> have in previous jobs).  We ship latex generated manuals in PDF format for
>
> You guys have it way to easy! :)  All our apps must ship with help
> files, and we have a separate installation PDF. Our end-users are not
> the most computer literate, but they know everything about Maths and
> Science.

This is a bit like the argument about whether code should be commented
or properly-written. I normally argue for copious comments in source,
but at the same time I think I favour properly-designed forms and
components which don't need on-screen help.

Having a decent manual, possibly with weak linkage to the app so that it
opens on the right page (something that PDF is bad at) is a different issue.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Mattias Gaertner
In reply to this post by Graeme Geldenhuys


Graeme Geldenhuys <[hidden email]> hat am 18. Juli 2012 um 19:53 geschrieben:

> Hi,
>
>
> > I think Reinier and I are saying that the need in the current case is how to
> > intercept F1 and recover an associated keyword, and how to pass that keyword
> > to lhelp.
>
> Surely the "capturing of the F1 key press" functionality already
> exists in LCL? I also see TControl.HelpType, TControl.HelpContext,
> TControl.HelpKeyword and Application.HelpFile properties... Are they
> just for show (not functional yet)?

 

They do work.

See here an example with HTML pages:

http://wiki.lazarus.freepascal.org/Add_Help_to_Your_Application

 

>
> Another problem I spotted was with the Application.HelpCommand()
> signature. It's got the signature designed by Borland Delphi v1
> (somewhere around then) for the use with the very old WinHelp help
> viewer and the long discontinued .HLP files.

 

There are:

function HelpCommand(Command: Word; Data: PtrInt): Boolean;
function HelpContext(Context: THelpContext): Boolean;
function HelpKeyword(const Keyword: String): Boolean;

 

The Keyword can be an arbitrary string. In the HTML viewer it is the path behind the BaseURL.

 

 

> I've already raised this> issue some years back, but received my usual answer that it will not
> be changed - go figure. Anyway, a more sane signature for
> Application.HelpCommand() would be like Delphi & Kylix defined it for
> the CLX framework. As a matter of fact, the help system for CLX was
> designed to be cross-platform and uses Interfaces to be very flexible.
> It is probably the cleanest help system design I have ever seen, and
> it supports multiple help viewers too. Kylix even came with two
> reference implementations - a Man Page viewer and a HyperHelp viewer.

 

The current help system knows viewers and databases (= sources). It's not clx compatible though.

 

Mattias

 


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

[Lazarus] Application context-sensitive help using the IDE/lhelp protocol was: Building help files: the nitty-gritty

Reinier Olislagers
In reply to this post by Reinier Olislagers
On 17-7-2012 10:36, Reinier Olislagers wrote:
> On 17-7-2012 10:15, Mark Morgan Lloyd wrote:
>>From another outsider's view, wouldn't this be a solution:
> 1. document the IPC mechanism used for communication between IDE and
> lhelp so application developers can use it

Added some notes on
http://wiki.freepascal.org/IDE_Development#Working_8
Although that page says: "This page contains notes for lazarus core
developers about ongoing development." it seems like it can serve as
documentation of realized development as well.

See lazarus\components\chmhelp\democontrol for a project that
demonstrates IPC communication.

The source code
(lazarus\components\chmhelp\packages\help\lhelpcontrol.pas) is quite
legible... even for me ;)
While I've submitted some more comments in issue 22467, I think it can
serve very well as documentation for the protocol.
AFAIU it could be used as-is in applications, perhaps aided by taking
inspiration from the code in
lazarus\components\chmhelp\packages\idehelp\lazchmhelp.pas

Creating a component that includes lhelpcontrol added with some
functionality from chmhelppkg should be quite doable.

I can't seem to find any license info for these packages though. Is it
modified LGPL?

> 2. compile and distribute lhelp with your application... should be
> possible already, shouldn't it?
> 3. in application: start lhelp and pass messages using 1.


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Graeme Geldenhuys
In reply to this post by Mark Morgan Lloyd
On 18 July 2012 20:15, Mark Morgan Lloyd
<[hidden email]> wrote:
> the same time I think I favour properly-designed forms and components which
> don't need on-screen help.

Some of our apps have advanced features. eg: Dynamic views that the
user can customise, thus changing what they see, and how the data is
presented. We supply some default views, which they can use to base
there views on, or create new views from scratch. The "what is a
view", and "how to create your own views" are things that appear in
the application help. Then we also have some help and transaction
examples in our accounting section of the application. People learn
best by example - thus, that is in the application help. We don't
display detailed help per widget, but rather an overview of each
dialog, and what is is for. And more detailed help for things like the
two examples I listed above.


> Having a decent manual, possibly with weak linkage to the app so that it
> opens on the right page (something that PDF is bad at) is a different issue.

We even have one-to-one training sessions on our applications and
business practices (we are a franchise business)... and amazingly we
still get phone calls about certain things. :)


--
Regards,
  - Graeme -


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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Application context-sensitive help using the IDE/lhelp protocol was: Building help files: the nitty-gritty

Mattias Gaertner
In reply to this post by Reinier Olislagers


Reinier Olislagers <[hidden email]> hat am 19. Juli 2012 um 10:06 geschrieben:

>
> I can't seem to find any license info for these packages though. Is it
> modified LGPL?

 

Modified LGPL 2, same as the LCL.

I added the note in the package.

 

 

>
> > 2. compile and distribute lhelp with your application... should be
> > possible already, shouldn't it?

 

yes

 

> > 3. in application: start lhelp and pass messages using 1.

Mattias


--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Reinier Olislagers
In reply to this post by Graeme Geldenhuys
On 19-7-2012 10:09, Graeme Geldenhuys wrote:
>> > Having a decent manual, possibly with weak linkage to the app so that it
>> > opens on the right page (something that PDF is bad at) is a different issue.
> We even have one-to-one training sessions on our applications and
> business practices (we are a franchise business)... and amazingly we
> still get phone calls about certain things. :)

LOL ;)

<cynical>As always, it's a careful balance between providing help[1]
that nobody reads versus not providing any help which users can then
complain about ;)</cynical

[1] And the advanced version: help that actually helps vs help where
some keywords are thrown together in order to give the appearance of
having made the effort...

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Application context-sensitive help using the IDE/lhelp protocol was: Building help files: the nitty-gritty

Mark Morgan Lloyd
In reply to this post by Reinier Olislagers
Reinier Olislagers wrote:

> On 17-7-2012 10:36, Reinier Olislagers wrote:
>> On 17-7-2012 10:15, Mark Morgan Lloyd wrote:
>> >From another outsider's view, wouldn't this be a solution:
>> 1. document the IPC mechanism used for communication between IDE and
>> lhelp so application developers can use it
>
> Added some notes on
> http://wiki.freepascal.org/IDE_Development#Working_8
> Although that page says: "This page contains notes for lazarus core
> developers about ongoing development." it seems like it can serve as
> documentation of realized development as well.
>
> See lazarus\components\chmhelp\democontrol for a project that
> demonstrates IPC communication.
>
> The source code
> (lazarus\components\chmhelp\packages\help\lhelpcontrol.pas) is quite
> legible... even for me ;)
> While I've submitted some more comments in issue 22467, I think it can
> serve very well as documentation for the protocol.
> AFAIU it could be used as-is in applications, perhaps aided by taking
> inspiration from the code in
> lazarus\components\chmhelp\packages\idehelp\lazchmhelp.pas
>
> Creating a component that includes lhelpcontrol added with some
> functionality from chmhelppkg should be quite doable.

I was working through stuff last night and could see where it was based
on SimpleIPC, with the socket name passed as a parameter to the lhelp
program. So provided that an app can grab F1 it doesn't look too bad.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Building help files: the nitty-gritty

Marco van de Voort
In reply to this post by Graeme Geldenhuys
On Wed, Jul 18, 2012 at 07:26:29PM +0100, Graeme Geldenhuys wrote:
> > (Only one helpfile per app?)
>
> No, you can concatenate multiple help files, specify a help directory
> (instead of a file), specify an environment variable etc... DocView is
> very flexible with this.


 
> > I don't ship Lazarus applications.
>
> :-/   Time to speak to your boss then.

It's mostly my call. There is nothing much to gain there.
 
> > At work I use Delphi, but I don't ship help with those either.  (though I
> > have in previous jobs).  We ship latex generated manuals in PDF format for
>
> You guys have it way to easy! :)  All our apps must ship with help
> files, and we have a separate installation PDF. Our end-users are not
> the most computer literate, but they know everything about Maths and
> Science.

Well, the pdf manuals are on average 100-150 pages, but sometimes 300 pages,
40-60% of which is custom per project. Then on top of that, blueprints and
BOMs of all mechanical parts.

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
123456