Hi,

This is a classic case of seeing a problem for so long that later you don't even realize it is there. In all my years of working on computers, Lazarus is the *only* program that specifies font sizes as a negative values. Why? No other GTK2 application shows font sizes as negative values.

See attached screenshot.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: font_size.png
Type: image/png
Size: 3902 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090815/bc76e864/attachment.png>

Lazarus is not a tool for any user - it is a tool only for programmers. As an ex-delphi programmer you should know a difference between negative and positive font sizes.

Best regards,
Paul Ishenin.

Lazarus is not a tool for any user - it is a tool only for programmers. As an ex-delphi programmer you should know a difference between negative and positive font sizes.

What about newcomers?
Should we say: "Learn Delphi first, then come back here?" :)

Lazarus has been breaking Delphi backward-compatibility for a long time already. It's natural to get rid of negative font heights, no?

thanks,
dmitry

Paul Ishenin wrote

> See attached screenshot. Lazarus is not a tool for any user - it is a tool only for programmers.

Just because there is an inner technical reason for something, does not mean that needs to be reflected in the user interface.

As an ex-delphi programmer you should know a difference between negative and positive font sizes.

Correct, I am an ex-delphi programmer. I used D5, D6, D7 and Kylix 2 & 3. But to be honest, I have no clue what you are talking about. I have no idea what negative fonts mean - please enlighten me. In the mean time, I'll try and Google for information.

It makes no sense to me. I select the font and size via the GTK2 font dialog, then magically Lazarus changes my 12pt font (from the font dialog) to -12. Then when I select the font size combo dropdown, -12 is the only negative value listed, all other values are positive.

I have never seen any problem (IDE's included) showing negative font values. I'm loading Kylix in a VM session now just to make sure.

Does anybody else excluding Paul know what negative fonts sizes mean? Please answer, I would like to know if I missed something major in my 15+ years of working as a developer.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Does anybody else excluding Paul know what negative fonts sizes mean?

I would like to know that too. I also don't have any idea what negative font sizes could mean. Ok, that could be due to the fact that I havened used Delphi heavily and I am just beginning with Lazarus. But even using help on such entries does not show any hint.

I admit a little explenation would help since it is not so trivial.

A positive fontsize is the size of a font in points A negative fontsize is the size of a font in points including the internal leading at the top of the line

For fontheights it is the opposite since the height and size are related like:
fontsize = -fontheight * 72/pixelsperinch

What happens is I think that the fontheight is stored (positive) which results in a negative size.

Marc

This seems not to be a general concept (Windows only?). While searching for negative font sizes on the web I found this:

http://cfsearching.blogspot.com/2008/03/imagedrawtext-negative-font-sizes-give.html

which shows a completely different effect when using negative font sizes.

This is how it is defined in delphi. Lazarus tries to be compatible with that.

Iirc Iv'e seen this on carbon too, but thats not realy relevant for lazarus.

Marc

Thank you, now I don't feel so alone. :-)

I tried various searches in Google and couldn't find anything either. If it is something specific to Delphi, then all I could think of is that whatever programmer conquered up negative font size was high on crack at the time. :-)

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Google found for me http://support.microsoft.com/kb/32667

It is not Delphi specific, but has windows roots.

Vincent

Marc Weustink wrote

I admit a little explenation would help since it is not so trivial.

Thanks for the explanation - definitely not a "general knowledge" thing. Searching in Google I found no mention of this in any other GUI toolkits or IDE's - so I gather this is a Delphi VCL specific thing?

Does the rest of LCL's TFont work the same, or is this negative size font only implemented in TSynEdit?

A positive fontsize is the size of a font in points A negative fontsize is the size of a font in points including the internal leading at the top of the line

So in GTK1, GTK2, Qt and the myriad of other GUI toolkits with font dialogs. When the user selects 12pt font, which one is it. Option 1 or 2 above?

So where exactly or why would you use the negative font size? Like I said, I have never seen this anywhere else but in Lazarus IDE.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Vincent Snijders wrote

Google found for me http://support.microsoft.com/kb/32667 It is not Delphi specific, but has windows roots.

I still don't know how they got to negative font height idea. The Xlib and Xft font metrics documentation, and various other docs on the net, defines font height as the Ascent + Descent. And that is how I implemented it in fpGUI, and how it's implemented in a few other GUI toolkits I looked at.

Even if it comes from Microsoft (and note, not everything from Microsoft is great), I have never seen anybody specify a font height in MS Office using a negative value. Then again, I switched to OpenOffice years ago.

I really don't think it makes sense using it in the Lazarus IDE.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

What about newcomers? Should we say: "Learn Delphi first, then come back here?" :)

That's the current state. Without the Delphi documentation and OH every newcomer to Lazarus is definitely lost :-(

Lazarus has been breaking Delphi backward-compatibility for a long time already. It's natural to get rid of negative font heights, no?

Introducing more sophisticated features can mean more work at design time. But I agree that the handling of fonts, with regards to baseline adjustment and font sizes, could be improved with dedicated properties.

DoDi

Does anybody else excluding Paul know what negative fonts sizes mean? Please answer, I would like to know if I missed something major in my 15+ years of working as a developer.

AFAIR the positive and negative values reflect the inclusion and exclusion of the "external leading" of an font, affecting the line spacing of multi-line text.

In controls with a single line of text (labels, edits, buttons...), no extra line spacing should be added to the font. In controls with multiple lines of text, extra line spacing should be inserted in order to make the text more readable.

Delphi allows to encode both font properties in an single property value, but it would be more obvious to the user, when additional properties would reflect the according effects.

I'm not sure how the Delphi font settings are translated into Windows font properties. Windows text output has traditional problems with fonts and controls, because the text is painted into surrounding boxes independently, so that text in a row of boxes can sit on different baselines. Other widgetsets may have similar problems, when e.g. borders of various sizes affect the remaining room for text. Aligning borderless labels and edit boxes is a PITA, that could be cured by practical and meaningful layout rules for such bread-and-butter components.

DoDi

There is a difference between font size and height. From the D7 help:

---------------------------------------------------------------------------- The value of Height can be obtained from the point size using this formula:

Font.Height = -Font.Size * Font.PixelsPerInch / 72

When the Height property has a positive value, the Size property has a negative value. When the Size property has a positive value, the Height property has a negative value. ----------------------------------------------------------------------------

I never thought this strange. The positive one is the one that was actually set, the negative one was the one that was calculated from the set one ?

Am I missing something ?

Michael.

Michael Van Canneyt wrote

Am I missing something ?

Yes, why is it an option in the first place? No other application asks the user for the Font Size or Font Height. If the one can be calculated from the other, then just give us the ONE normal option - Font Size. Anything else is just confusing to the user.

From a user interface point of view it makes NO sense. If a developer with 15+ years experience does know what that option means, what do you think a newbie developer is going to think?

Maybe we can clarify the option via a nice tooltip that reads: "Please download Delphi and read the help regarding Font Height. Also pay close attention to the formula, it might be important, and there might be a quiz at the end. Then come back to Lazarus with your new found knowledge, where you can specify a font via the Font Height property OR what 99.9999% of all other applications do, the Font Size (in points) property."

Even Gnome with it's sh*tty and inconsistent UI interfaces, do not give two font height/size options. KDE that blasts users away with thousands of options also only uses font size (never font height).

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: font_combo.png
Type: image/png
Size: 7236 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090815/89c3362f/attachment-0001.png>

User, yes. programmer: no.

As I understood it, the difference is as follows:
- Setting size selects the point size of the font, no matter what the DPI is.
- Setting height sets the pixel size of the font, and then the correct point size is calculated (using DPI) so the height is reached.

The second option had to be chosen if you wanted your font to be the same pixel height no matter what the DPI.

Makes sense to me, we only use height at work, never ever size.

Michael.

Now why couldn't you explain it like that in the first place! ;-) If the wiki help does not mention what you said, I'll copy and paste yours exactly, so others understand it as well. Not even the Delphi help that you quoted, made it as simple and clear as your explanation.

Maybe it will help if the caption was changed from "Editor font height" to "Height in pixels". No point in repeating the "Editor font" part of the caption, because the whole bounding groupbox is related to the Editor Font. Also a tooltip saying that if a negative value is displayed, is has been calculated from the point size might be a nice hint too. Just a thought.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

It should be that way, but font selection in Lazarus editor configuration is simply buggy as hell.

For me (on Windows XP), initially there is 18 in 'font size' combo. Pressing button with ellipsis displays Windows font selection dialog, in which size is set to 14, and the font sample in preview looks a bit larger than the font in Lazarus. After closing font selection dialog by clicking 'OK' without any changes, the value in 'font size' combo changes to -19, and the font in Lazarus preview becomes about twice bigger than it was.

Regards,
Sergei

- Setting size selects the point size of the font, no matter what the DPI is. - Setting height sets the pixel size of the font, and then the correct point size is calculated (using DPI) so the height is reached.

So it does work the following way:

2.) If I use positive values, it's just the number of pixels height (which could be different measured in millimeters on different screens)

1.) If I use negative values it would be the same size (in millimeters) on all screens. The number of pixels would be calculated by using some information about the DPI on the screen

Is that true? Does Free Pascal calculate the number of pixels if I start my program on different screens?

Yes, but a programmer is a user to, depends on context.

In the object inspector, the positive and negative values should be displayed.

But on the editor options dialog, I don;t actually see the point. The Editor option dialog doesn't have a "Size" and a "height" field, it has one field only.
IMHO the dropdown should be the same as the listbox on the font-selection-popup-dialog => all positive values. It can accept negative values, but only if manually entered by the user.

Martin

It uses the TFontDialog.

Please create a bug report.

Mattias

I think it should be like this in Delphi:

Since size and height change the same value with a slightly different meaning (PPI) whichever value was set,
the other one is rounded and gets a negative value.

If you set size you should get a negative height and vice versa.

Please help and write your knowledge to the lazarus help.

Mattias

Mattias Gaertner wrote

Please create a bug report.

Done: http://bugs.freepascal.org/view.php?id=14357

Sergei

Yes.

Does the rest of LCL's TFont work the same, or is this negative size font only implemented in TSynEdit?

It should. Any diference on whatever widgetset is a bug.

Should be 1 since positive.

So where exactly or why would you use the negative font size? Like I said, I have never seen this anywhere else but in Lazarus IDE.

I usually see them when setting heights (in pixels). Agreed, imo, they shouldn't be shown in lazaris as negative.

Marc

> Should we say: "Learn Delphi first, then come back here?" :) That's the current state. Without the Delphi documentation and OH every newcomer to Lazarus is definitely lost :-(

That would be a guideline if it worked. But the problem is, that you cannot rely on the Delphi documentation when using Lazarus because there are lots of details where Lazarus differs from Delphi. So the conclusion is, that no (usable) documentation exists for Lazarus. You have to try and ask the forum if in doubt. That's not a satisfiable situation but as long as noone hast the time (and knowledge) to update the Lazarus help it seems unavoidable.

2009/8/16 J?rgen Hestermann :

forum if in doubt. That's not a satisfiable situation but as long as noone hast the time (and knowledge) to update the Lazarus help it seems unavoidable.

Not to mention the major problem with Lazarus IDE help. It's only in wiki form, and only available online. Help should at least be available in a offline format. I often work at home in a offline state and I am sure I am not the only one that doesn't have a "always on" internet connection.

Lazarus has "lhelp" included with the source code, so why not use it for the ide help? fpdoc can still be the format used for writing the help and as far as I know fpdoc can also generate CHM help format. Even simple HTML help generate by fpdoc will be better than wiki-only format help.

Regards,
- Graeme -

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

Help should at least be available in a offline format. I often work at home in a offline state and I am sure I am not the only one that doesn't have a "always on" internet connection.

That's true. But the first step should be to have a usable that's available it should not be too hard to compile it for offline use somehow.

J?rgen Hestermann wrote

That's true. But the first step should be to have a usable help at all. If that's available it should not be too hard to compile it for offline use somehow.

Can you help Chris Kirkpatrick to improve it?

Best regards,
Paul Ishenin.

First of all:
Take a look in the wiki log and you will see that every day things are updated or added.

About the forum vs wiki:
There are many experts in the various forums writing good advices and sometimes lengthy explanations. I wish they would instead add the hints to the wiki and just post a link in the forum.

It is true, that the quality of the Delphi help is really good - and in too many areas better than the lazarus help.
But "no usable documentation" is a bad exaggeration. There are for example more than 1000 wiki pages and the lcl fpdoc contains more than 30.000 notes.

Mattias

> That's true. But the first step should be to have a usable help at > all. If that's available it should not be too hard to compile it for > offline use somehow. Can you help Chris Kirkpatrick to improve it?

I would like to but I need the help myself first ;-) How could I document what I don't know (for sure)? I didn't do very much with Delphi yet and I began with Lazarus only recently. So it's a hen or egg problem.

Make sure and write down, what you know.
Editing the wiki is as easy as editing a text file.

See here for some more types of help
http://wiki.lazarus.freepascal.org/Creating_IDE_Help

I didn't do very much with Delphi yet and I began with Lazarus only recently. So it's a hen or egg problem.

Mattias

Make sure and write down, what you know. Editing the wiki is as easy as editing a text file. See here for some more types of help http://wiki.lazarus.freepascal.org/Creating_IDE_Help

I just tried to compile lazde but got the following messages:

---------------------------------------------------------- windres: no resources
Hint: Start of reading config file
D:\Programme\lazarus\fpc\2.2.5\bin\i386-win32\fpc.cfg Hint: End of reading config file
D:\Programme\lazarus\fpc\2.2.5\bin\i386-win32\fpc.cfg Free Pascal Compiler version 2.2.5 [2009/07/27] for i386 Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Win32 for i386
Compiling lazde.lpr
lazde.lpr(8,40) Hint: Unit "PkEditor" not used in lazde lazde.lpr(9,44) Hint: Unit "LazDEMsg" not used in lazde lazde.lpr(9,65) Hint: Unit "pgEditor" not used in lazde Compiling resource D:\Programme\lazarus\doceditor\manifest.rc D:\Programme\lazarus\fpc\2.2.5\bin\i386-win32\windres.exe: no resources lazde.lpr(17,1) Error: Error while linking
lazde.lpr(17,1) Fatal: There were 1 errors compiling module, stopping ----------------------------------------------------------

I have no idea why it failed.
Anybody else?

I usually edit the xml files by hand, because lazde does some changes in the xml which make it hard to see in the diff what I actually modified.

I usually edit the xml files by hand, because lazde does some changes in the xml which make it hard to see in the diff what I actually modified.

What about the fpdoc editor?

Mattias

If you're compiling under Windows the error may be a missing manifest file. Locate a copy of manifest.rc somewhere in a subdirectory of your Lazarus directory. (If there is more than one I think any of them will do) and copy it into the lazde project directory, where windres.exe will find it at compile time without complaining.

yours

Howard

I removed the old windows.rc and added the default, that the IDE creates when using the project option.

Mattias

First of all: Take a look in the wiki log and you will see that every day things are updated or added.

That's no excuse for the absence of a compact general documentation or help on all classes, properties and methods. The interfaces don't change so often, or cannot be changed at all for Delphi compatibility.

About the forum vs wiki: There are many experts in the various forums writing good advices and sometimes lengthy explanations. I wish they would instead add the hints to the wiki and just post a link in the forum.

Just *lengthy* explanations are not the base of useful OH.

All contributions should be verified, by people with according knowledge, i.e. the implementors in the first place. These also can add hints on topics which are subject to changes.

Instead of adding to the wiki, notes also could be created by fpdoc and added to the SVN, provided that every user has write access to the documentation folder.

It is true, that the quality of the Delphi help is really good - and in too many areas better than the lazarus help. But "no usable documentation" is a bad exaggeration. There are for example more than 1000 wiki pages and the lcl fpdoc contains more than 30.000 notes.

Useful help must be structured, with links from the general keys (identifiers in source code) to all the related information. It must not be scattered across a number of unrelated and unlinked places.

Delphi help is good because it is structured, and every piece has its place in that structure. It has taken CG many years, to find a useful replacement for the old WinHelp, and to move all contents to the new structure. That's not fun, that's hard work. I already have considered to write my own documentation, and to sell it as a service...

Lazarus also could ask CG for a license for the Delphi help, so that most parts can be ported by copy&paste. Then it were up to the implementors, to add the Lazarus specific notes, and finally everybody could add examples and other stuff.

DoDi

Editing the wiki is as easy as editing a text file.

That doesn't explain why it isn't used by those people, that implement Lazarus and have all knowledge about what they did :-(

DoDi

This thread seems to have changed into one that discusses the provision of Help for Lazarus, so I'm going to start a new thread.

I am currently trying systematically to produce documentation for all the classes in the LCL, and the tool that I have found most useful is the FPDoc editor in the Lazarus IDE. There are a few things it does not readily address, such as the provision of a short description for the Unit files themselves - I have usually done this by hand, and the problem of duplicate declarations - FPDoc usually constructs documentation files from the last delaration in the pascal source file, so if the XML tags have been attached to a forward declaration, they often get missed, or if there are alternative versions of a declaration, onely one of them gets picked up.

However, by and large, the FPDoc editor is an excellent tool, and I would encourage anyone trying to produce Help to use it as the first resource.

As well as providing detailed descriptions of all the classes, procedures etc in the Lazarus code, we need to produce a lot of How-to type documentation, and this process is still in its infancy. There is a lot of good stuff in the wiki, but it is not very systematic. Some of the developers are writing a Lazarus book, and we should encourage this to form the basis of a good manual. We need lots of ideas, and a lot of work needs to be done. All offers of assistance will be welcome.

Chris

That's no excuse for the absence of a compact general documentation or help on all classes, properties and methods.

<snip>

All contributions should be verified, by people with according knowledge, i.e. the implementors in the first place.

<snip>

Useful help must be structured, with links from the general keys (identifiers in source code) to all the related information. It must not be scattered across a number of unrelated and unlinked places.

<snip>

I already have considered to write my own documentation, and to sell it as a service...

So you know how good help should look like and how it is created and want the developers to do the job in addition to their development efforts for free. But you are willing to do the work if you can earn money with it? You sound really like a nice and helpful person.

Lazarus also could ask CG for a license for the Delphi help, so that most parts can be ported by copy&paste.

Are you serious?
I am sure BorInprGear are more than willing to hand over a license for their help so that Lazarus can use it for free.

I hope you are not the kind of person this mail makes you look like.

S.

2009/8/16 Mattias Gaertner :

Editing the wiki is as easy as editing a text file.

Why couldn't the Lazarus IDE help be in fpdoc format? That way we could use the 'lazdoc' editor, or maybe even use the internal fpdoc editor in some way. Why only online help?

Regards,
- Graeme -

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

fpdoc is for sources, not for arbitrary help.

Why only online help?

The offline version of the wiki is a ToDo.
Some people have already done some work, but afaik no one has put all together and made it easy to use.

Mattias

2009/8/16 Hans-Peter Diettrich :

Such comments will not get you far. Lazarus is a community project. So help by contributing!

Instead of adding to the wiki, notes also could be created by fpdoc and added to the SVN, provided that every user has write access to the documentation folder.

Nope, all you need to do is generate a patch against the documentation and submit it here or preferably in mantis where somebody with write access can submit it. The FPC documentation and LCL documentation works like that.

I think the Lazarus IDE documentation should too. I hate online documentation, I need things local where it is fast to view. I can (and have) done that for the FPC compiler and it works well.

BTW: If you run Linux and own a copy of Kylix or maybe have the Kylix Open Edition still lying around, you can use it's help directly from the Lazarus IDE. I enabled my Kylix 3 help (as described on the wiki). I now have context sensitive help on anything related to Object Pascal.

Regards,
- Graeme -

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

2009/8/16 Mattias Gaertner :

fpdoc is for sources, not for arbitrary help.

Well the current IDE help in the wiki is very basic and very easily duplicated in fpdoc. Whatever fpdoc doesn't support, I am sure it wouldn't be to hard to add that extra functionality. At least that way we can have PDF, CHM or HTML help for the IDE.

Regards,
- Graeme -

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

I have used the 'topic' tag in FPDoc to produce some general 'How-To' sections (see the documentation for StdCtrls, DBCtrls for examples) and in some cases have either replicated the FPDoc articles in the Wiki or replicated Wiki articles in the FPDoc XML topic (eg some parts of Grids).

The conversion from Wiki to XML is not always straightforward, but could form the basis of more extensive online documentation if other users/developers feel that this would be worthwhile.

Chris

Mattias Gaertner wrote

What about the fpdoc editor?

Never used it, I'll try next time I edit help files

The internal fpdoc editor is very nice and doesn't reformat the xml file. Only down side is that the internal fpdoc editor doesn't have all the features of the lazde program.

Either way, I use the internal fpdoc editor for 95% of my document writing. The other 5% is done manually via a standard text editor.

One thing the internal fpdoc editor editor cannot do is document a unit description. The other thing that would be nice is a button to include the short description in the long description text. Lazde has this. I often start my long description using the same text as the short description.

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

What is the problem with lazde?

One thing the internal fpdoc editor editor cannot do is document a unit description.

Make a proposal.

The other thing that would be nice is a button to include the short description in the long description text. Lazde has this. I often start my long description using the same text as the short description.

Normally the long description is shown just below the short description. On the short description page there is room for an extra button. On the long description page there is no room. Maybe it could be added to the popup menu.
Make a proposal.

Mattias

This way a lot of projects ended up unfinished :-( If every contributor does only what he likes to do, and asks others to take the nasty remaining things on their shoulders, then those things never will be done.

You note that little difference, that allows to write a mail or into the wiki, and everything's done?

Of course it would be a kick if all patches to the documentation are reviewed by the developers, before they add the patch to the repository. But as long as the creation of an patch is required *only* due to the lack of immediate write access, it's another hurdle for all underprivileged contributors.

I think the Lazarus IDE documentation should too. I hate online documentation, I need things local where it is fast to view. I can (and have) done that for the FPC compiler and it works well.

Right, I also prefer local help, but it should be possible to share local docs with the community in the same easy way.

That's why I suggested an "official" request, from the Lazarus team to CodeGear, for a license of the Delphi help. I already started to import parts of the Delphi OH, but without a license agreement I cannot make my work available to the community.

DoDi

Mattias G?rtner wrote

> One thing the internal fpdoc editor editor cannot do is document a > unit description. Make a proposal.

Here is an example. The tiTokenLibrary.pas unit documentation. You cannot edit this with lazde or the internal fpdoc editor. I have to manually edit this is the xml file.

http://opensoft.homeip.net/tiopf/core/titokenlibrary/index.html

and here is the actual documentation for that unit (overview).

======================
<module name="tiTokenLibrary">
<short>String tokenizer library</short>
<descr>
<p>The TToken tokenizer is extremely flexible, being able to tokenize quite
complex strings. See the unit tests for examples of these. It is also a lot faster than the previous string tokenizer function in tiUtils. </p>
======================

Possible way I thought of how the internal fpdoc editor could do this. When you put the cursor on the "unit tiTokenLibrary" line of the unit, then fpdoc editor should edit the module tag documentation.

Normally the long description is shown just below the short description.

Generated documentation
http://opensoft.homeip.net/tiopf/core/titokenlibrary/ttokens.html

and the actual xml doc file. As you can see I use the "printshort" tag, so the short description is duplicated in the long description. So if I update the short description, the long description (first sentence) is automatically updated. No manual text duplication.

===========================
<element name="TTokens">
<short>This is the string tokenizer</short>
<descr>
<p>
<printshort id="TTokens"/>. It is based on a Finite State Machine design pattern. The following image shows how the State Machine works.</p>
<img file="../../images/tiTokenLibrary_Diagram.png" name="tokenlibrary_overview" alt="tiTokenLibrary overview"/> </descr>
===========================

On the short description page there is room for an extra button. On the long description page there is no room. Maybe it could be added to the popup menu. Make a proposal.

Maybe add a new button as indicated in the attached image. But I think an even better option will be a popup menu item when your right click over the long description memo - "Insert printshort tag".

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

I didn't know that the unit description tags use the same format as the elements.
Ok, now you can edit it in the fpdoc editor.

> Normally the long description is shown just below the short description. Generated documentation http://opensoft.homeip.net/tiopf/core/titokenlibrary/ttokens.html

:)

[...] Maybe add a new button as indicated in the attached image. But I think an even better option will be a popup menu item when your right click over the long description memo - "Insert printshort tag".

I added the popup menu item.

Mattias

Mattias G?rtner wrote

I didn't know that the unit description tags use the same format as the elements. Ok, now you can edit it in the fpdoc editor.

Excellent, it works nicely now. Thanks!

Thank you again. Please see attached patch. I added another popup menu that inserts the <printshort> tag instead of copying the short description text.

http://bugs.freepascal.org/view.php?id=14369

Regards,
- Graeme -

Don't hold your breath.

And IMHO documentation should be a totally free asset, including publishing rights. I think the chance is nearly zero to get it with an appopriate license from Embarcadero.

PasDoc takes the short description from the first sentence of the long description - unless an abstract is given explicitly.

DoDi

And IMHO documentation should be a totally free asset, including publishing rights. I think the chance is nearly zero to get it with an appopriate license from Embarcadero.

All we need is an agreement that the information, as available in the OH files, can be reused literally as far as required. Information for itself is not protected, as aren't citations.

Some corrections, clarifications and updates are required in many cases. I could rewrite most topics in my own words, in German, but then somebody else has to provide an English translation.

DoDi

This is lovely, but we have lost all the Cut, Copy and Paste options from the popup menu in the <descr> box.
Regards - Chris

2009/8/20 Chris Kirkpatrick :

> This is lovely, but we have lost all the Cut, Copy and Paste options from the popup menu in the <descr> box.

Oops, that is true. I guess we need to merge the original (default) popup and the new items. Or simply use the keyboard shortcuts which should still work.

Regards,
- Graeme -

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