Well, I've managed to custom draw cells, but it's a bit rough. Delphi seems to have a TStringGrid.drawcell function, but I couldn't find an equivalent in FPC/Lazarus. Is there one? Or will I be doomed to drawing ugly stringgrids? (Currently just changing font color + background color, following this: http://www.daniweb.com/forums/thread125428.html# )

2009/8/23 Matt Shaffer :

Did you read grids reference ? -
http://wiki.lazarus.freepascal.org/Grids_Reference_Page StringGrid

Missed that page, thanks. Quite a bit different from Delphi, but everything's drawing to my liking now.

I'd just like to say one thing about my last message; although now I have everything drawing happily, it's very CPU intensive :S. Source: http://pastebin.com/m78f85f6c
I'm thinking it's because it's running all of that code each time it repaints? Is there a way to, I don't know, "render" the grid to prevent so many calculations from being done?

Tomasz Wi?ckowski wrote

Did you read grids reference ? - http://wiki.lazarus.freepascal.org/Grids_Reference_Page StringGrid

Why is most of that information and method documentation not in the fpdoc format included with LCL. There are some documentation in the fpdoc format, but the wiki pages seems more extensive. Such information should rather be in the fpdoc LCL (xml documentation) files/format.

Lazarus and LCL documentation seems too scattered for me! It makes it near impossible to find anything. And if you do find something, you have no idea if it is actually the most up-to-date information. The Lazarus project as a whole really needs to address this issue.

Regards,
- Graeme -

I guess the writer of this article found it easier to write it in the wiki and I am happy he did, I rather have this in the wiki then remaining just in the head of the doc writer.

Lazarus and LCL documentation seems too scattered for me! It makes it near impossible to find anything. And if you do find something, you have no idea if it is actually the most up-to-date information. The Lazarus project as a whole really needs to address this issue.

Any ideas how to accomplish this? Without hiring a dedicated document writer/manager?

Vincent

--- El dom 23-ago-09, Matt Shaffer escribi?:

If using OnPrepareCanvas event, try to use Canvas properties instead of grids properties, for example changing grid's font results in new whole windows invalidates, the same for grid.color. So please try to see if using grid.canvas.font(.color, etc) and grid.canvas.brush.color makes any difference.

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Vincent Snijders wrote

Any ideas how to accomplish this? Without hiring a dedicated document writer/manager?

For the LCL documentation, I think the fpdoc format is the best. There is no excuse not to use it. The Lazarus IDE also includes an internal FPDoc Editor (Views menu), which makes it really easy to document such classes. Then simply create a patch and submit it to Mantis or mailing list.

The nice thing of fpdoc is also that you can edit & view documentation while offline.

For the Lazarus IDE help - that is another story. fpdoc format does not seem to be the ideal format for the IDE (dialogs) help. I suggested the AsciiDoc format. I will continue with that idea my implementing a basic AsciiDoc help database backend and help viewer.

But TStringGrid is part of the LCL, so it should have it's documentation in the LCL fpdoc format. FPDoc has support for examples (code) and images. It also has support for extended Topics, to elaborate even more about a component etc...

Regards,
- Graeme -

It should not be too hard to write a small script which extracts the wiki documentation and formats it as fpDoc topics ? The wiki has very limited make-up possibilities, after all.

All the documentation manager would have to do is re-order and group the topics.

I'll see if I can cook something up.

Michael.

Do you want to take this information and put it put it in fpdoc format? You may consider the wiki a scrap book full of notes to be ordered in the right place, for which nobody has taken the time or given high enough priority yet. Jotting down a note in the wiki is really easy (with just a standard internet browser). Ordening and structuring takes more time. (And I don't consider it fun, so I won't do it unless paid.)

Vincent

Vincent Snijders wrote

Do you want to take this information and put it put it in fpdoc format? You may consider the wiki a scrap book full of notes to be

That's what I would like to do. So it will be ok if I cut & paste from wiki into fpdoc? That means reducing the content in the wiki page and rather place the content it in the fpdoc xml files.

If you suggest copy & paste (instead of cut & paste), then I don't see the point. Because then somebody else might continue adding to the wiki instead of the fpdoc xml - resulting in out-of-sync docs again. And the whole exercise would have been pointless.

Regards,
- Graeme -

I have no problem with cut and paste, if you put a link to the online docs instead. Please use wiki links, just in case the documentation is moved to another server, the wiki pages remain up to date:
[[doc:lcl/grids/tcustomstringgrid.html|TCustomStringGrid Reference]]

Vincent

who said anything about hiring anyone? what is wrong with those we currently have documenting what they know about and understand?????

What is wrong? According to Graeme, they are documenting in the wrong place: wiki instead of fpdoc.

I am more relaxed, I let everybody document where ever they want, it is better to have document in the 'wrong' place than understand the need to consolidate the information in the wiki to the fpdoc system, but for me that is a chore that is not fun to do and I would not volunteer for it. Maybe others will, so money is needed.

Vincent

I've already presented some thoughts on a new Lazarus documentation project, and I'm willing to assist in the development of an according database and (web?) interface. Unfortunately I'm very busy with another project right now, and need assistance for database and C/S programming.

DoDi

I suggested the AsciiDoc format. I will continue with that idea my implementing a basic AsciiDoc help database backend and help viewer.

Sounds very good, keep us informed! :-)

What's your open projects' number and priority? ;-)

DoDi

Jotting down a note in the wiki is really easy (with just a standard internet browser). Ordening and structuring takes more time. (And I don't consider it fun, so I won't do it unless paid.)

I think that the community will contribute to this tasks, too - provided a nice interface (interview/checklist/wizard style?) with immediate feedback.

DoDi

Managing links to registered and classified/indexed document sources would be sufficient, for now - IMO. Then we can look into a notification system, integrated somehow into/around updating document sources (wiki...), and tools to automate updating of the converted sources. Converting single articles manually IMO is a waste of time.

For an internal format I favor something like AsciiDoc, over XML. Unless a strict XML scheme[*] is used for structuring and indexing the entries, and a nice user interface for updating existing and indexing new entries exists.

[*]Limiting entries to a common XML structure makes XML itself obsolete, IMO.

DoDi

The intersection of the sets of people, who know about their code, and who document code, is almost empty :-(

DoDi

I understand the need to consolidate the information in the wiki to the fpdoc system, but for me that is a chore that is not fun to do and I would not volunteer for it. Maybe others will, so money is needed.

IMO doing documentation can be fun, when the entire community can participate easily, and according user-friendly tools exist. See the many wiki and mailing list contributions...

The "create an patch, submit, and we'll look after it" mentality is a fun killer :-(

DoDi