Re: [Lazarus] Flexible exporter for grid-like components

2016-05-07 Thread Werner Pamler
Am 06.05.2016 um 22:51 schrieb Bart: Don't you have svn commit (to LCL)? Only for "components". -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-06 Thread Jesus Reyes A.
En Fri, 06 May 2016 15:51:41 -0500, Bart escribió: On 5/6/16, Werner Pamler wrote: ... About writing a patch: Don't you have svn commit (to LCL)? If so, just commit it, since nobody seems to object to the basic philosophy of your idea and implementation. Once committed, others will participate

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-06 Thread Graeme Geldenhuys
On 2016-05-01 20:34, Werner Pamler wrote: > TStringGrid provides the methods SaveToCSVFile/Stream for saving the > grid content to a csv file or stream. This is very convenient for users, > but it is not very flexible: The export works only for the csv data > format, no html, no possibility to p

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-06 Thread Bart
On 5/6/16, Werner Pamler wrote: > In preparing a patch for a Mantis feature request I came across this > issue: fpc does already contain a series of exporters > (packages/fcl-db/export, component palette "Data Export"), among them a > TCSVExporter, TSimpleXMLExporter etc. I would create our

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-06 Thread Werner Pamler
Am 01.05.2016 um 21:34 schrieb Werner Pamler: TStringGrid provides the methods SaveToCSVFile/Stream for saving the grid content to a csv file or stream. This is very convenient for users, but it is not very flexible: The export works only for the csv data format, no html, no possibility to pl

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-02 Thread Bart
On 5/2/16, Werner Pamler wrote: > TLaz2DTextExporter, or TCustom2DTextExporter? Or anything else? I'm rubbish when it comes to coming up with good names ;-) > I could give the HTMLExporter a corresponding property. But I see the > main use case of html export in stand-alone html documents, the

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-02 Thread zeljko
On 05/02/2016 01:24 PM, Luiz Americo Pereira Camara wrote: Em 2 de mai de 2016 07:55, "Werner Pamler" mailto:werner.pam...@freenet.de>> escreveu: >> >> I would have the name of the base class (LazExporter) reflect that it >> is intended for use with "2D-Data", and that it exports text. > >

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-02 Thread Werner Pamler
Does not grid implies a 2D format? TLazGridTextExporter? TLazTextGridExporter? Is necessary Laz prefix? Bart was talking of the ancestor of TGridExporter and TListviewExporter. No, the Laz prefix is not necessary; TExporter, on the other hand, is a very simple name which could exist in some ot

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-02 Thread Luiz Americo Pereira Camara
Em 2 de mai de 2016 07:55, "Werner Pamler" escreveu: >> >> I would have the name of the base class (LazExporter) reflect that it >> is intended for use with "2D-Data", and that it exports text. > > TLaz2DTextExporter, or TCustom2DTextExporter? Or anything else? Does not grid implies a 2D format?

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-02 Thread Werner Pamler
I would have the name of the base class (LazExporter) reflect that it is intended for use with "2D-Data", and that it exports text. TLaz2DTextExporter, or TCustom2DTextExporter? Or anything else? The HTML exporter should not (or not always) write a complete HTML page, most likely I would use th

Re: [Lazarus] Flexible exporter for grid-like components

2016-05-01 Thread Bart
On 5/1/16, Werner Pamler wrote: > > I would greatly appreciate any comments. > Nice piece of work. I would have the name of the base class (LazExporter) reflect that it is intended for use with "2D-Data", and that it exports text. The HTML exporter should not (or not always) write a complete H