Re: [Lazarus] How TDBGrid works
Thanks for the explanation, with your demo its more clear to me. Regards, Ara -- http://www.fastmail.com - Choose from over 50 domains or use your own -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Flexible exporter for grid-like components
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 plug in other formats. It requires always a modification of the /grids /unit to extend these methods by additional options. And it works only with TStringGrid - there are other grid-like controls, such as custom "virtual" grids derived from TCustomDrawGrid, TListview in report mode, TKGrid and other third-party grids which are not supported: if they do not have such a method on their own the export code has to be re-written (often: duplicated). The attached file contains code for a flexibile export system for 2D-data classes which is open and can easily be extended to other formats and other controls. It essentially consists of two parts: * *TLazExporter *represents the file format. The class is abstract and provides the methods to write cells and rows to stream and file. I implemented an exporter for *csv *and *html *files for the lclbase package. But in addition there is also a dedicated SpreadsheetExporter which takes care of *Excel *and/or *Opendocument *file formats (using fpspreadsheet). * *TLazExporterLink *provides the data to be exported. It is an abstract class between the control to be exported and the writer. It exposes methods to navigate from cell to cell and row to row, and to define the strings assigned to each cell. I implemented a TGridExporterLink (accessing *TCustomStringGrid*, in the long run: *TCustomDrawGrid*) and *TCustomListView*. The same principle works for any other classes with 2D data arrays (matrix). The unit /GridExporter /exposes functions to write grid content to file and to stream. The exporter instance is passed as a parameter, i.e. it is very easy to switch from csv to hml or any other format provided the corresponding exporter is available. procedure ExportGridToFile(AGrid: TCustomStringGrid; AExporter: TLazExporter; const AFileName: String; AOptions: TGridExportOptions); overload; procedure ExportGridToStream(AGrid: TCustomStringGrid; AExporter: TLazExporter; AStream: TStream; AOptions: TGridExportOptions); overload; Similarly, there are also ExportListviewToFile/Stream procedures in the unit /ListViewExporter /for the export from a TListview. Properties of the exporter can be used to fine-tune the export. In case of the html exporter, for example, a set of css statements can be specified to format the exported html table: htmlexporter := THTMLExporter.Create; with htmlexporter do begin CSS.Add('table { border: 1px solid #FF; }'); CSS.Add('th { background-color: #FF; }'); CSS.Add('h1 { font-family:Helvetica, Arial, sans-serif; font-size:16pt; color:blue; background-color: #FF}; }'); end; ExportGridToFile(StringGrid1, exporter, AFileNameForGrid, [geoFixedRows, geoFixedCols, geoVisibleColsOnly]); ExportListViewToFile(Listview1, exporter, AFileNameForListView, [leoTitles, leoVisibleColsOnly]); In addition to these procedures there are overloaded versions taking the exporter class (instead of an exporter instance) as a parameter. In this way the default exporter parameters are applied during the export. Of course, these procedures can be added as methods to the classes referred to by the first parameter. The attached demo shows the exporter system at work. It requires no modification of any LCL packages or units. In the long run, however, I'd propose to add unit /LazExporter /to package /LazUtils /and /GridExporter /and /ListviewExporter /to package /LclBase /(/SpreadsheetExporter /would go to /laz_//fpspreadsheet/), and to make these modifications to the /grids /unit: * Extend the ExportGridToFile/Stream procedures to accept also TCustomDrawGrid descendants. This would be possible by introducing a virtual method GetCellText(Col,Row) to TCustomDrawGrid (or maybe even TCustomGrid) which would catch the cell text from a special event OnGetCellText; this would help to create "virtual" grids using TCustom(Draw)Grids. In case of the TStringGrid, of course, GetCellText would simply return the cell strings Cells[Col, Row]. * Replace the code in SaveToCSVFile/Stream by the csv exporter. I'd also vote to deprecate these methods because they are special cases of the csv exporter. * Replace the copy-to-clipboard code (CopyCellRectToClipboard) by the csv exporter. In addition, a html format could be written to the clipboard with almost no extra code. I would greatly appreciate any comments. 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
Re: [Lazarus] How TDBGrid works
Jesus, In that demo if I set BufferCount to 9 always get 9 records and even Query.RecordCount will be 9 even result is more. How can I get real count? I can get count before setting the link but is it the best way? How can I move or scroll link without moving Query? I want to scroll the grid and get new data without changing RecNo. In your example if I only got 9 record for example but I want for example 20th record. Regards, Ara -- http://www.fastmail.com - Accessible with your email software or over the web -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
On Fri, 06 May 2016 13:44:46 -0500, Aradeonas wrote: Jesus,In that demo if I set BufferCount to 9 always get 9 records and even Query.RecordCount will be 9 even result is more. How can I get real count? I can get count before setting the link but is it the best way? DbGrid does not do that, and it doesn't have to. And the best way would depend, I guess, on the specific situation and what set of components are being used. How can I move or scroll link without moving Query? I want to scroll the grid and get new data without changing RecNo. In your example if I only got 9 record for example but I want for example 20th record. Not sure if I understand the part on "moving the query", but using TDataset derived components, and without using the basic MoveBy, Locate, first, last, next or prev you can't. Some dataset descendants may have some properties that help at some cost, for example y you set PacketRecords:=-1 then sqldb will load all the records and in this case RecordCount may be reliable, that is if dataset is not filtered (or that seems to indicate the relevant documentation). Some datasets may actually return a valid record count, probably TDbf is in this case. In any case without using the mentioned basic operations you can't select records. Regards, Ara Jesus Reyes A.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
Thanks, It seems I should explain better. For RecordCount you are right and it seems DBGrid doesn't know correct number either otherwise it should has a better scroll size. I want to do something like DBGrid and for that I want to get only a part of data for example record 1000 to 1100 and for that I can set BufferCount to 100 but in this case I should navigate dataset to record 1000 to get these value but I prefer to not change RecNo and use something like DataLink's ActiveRecord that changes record you want without changing RecNo of Dataset. So if I have 1 Dataset that is fully load all 1500 record can I just print records from 1000 to 1100 without changing RecNo? Regards, Ara -- http://www.fastmail.com - Faster than the air-speed velocity of an unladen european swallow -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
On Fri, 06 May 2016 15:07:18 -0500, Aradeonas wrote: Thanks, It seems I should explain better. For RecordCount you are right and it seems DBGrid doesn't know correct number either otherwise it should has a better scroll size. I want to do something like DBGrid and for that I want to get only a part of data for example record 1000 to 1100 and for that I can >set BufferCount to 100 but in this case I should navigate dataset to record 1000 to get these value but I prefer to not change RecNo >and use something like DataLink's ActiveRecord that changes record you want without changing RecNo of Dataset. You can't, there is no way using TDataset facilities. But anyway, changing ActiveRecord *should* change RecNo (provided that RecNo is reliable, it definitively is not if Dataset.IsSequenced=false OR dataset is filtered), if it's not then you found a bug. So if I have 1 Dataset that is fully load all 1500 record can I just print records from 1000 to 1100 without changing RecNo? Regards, Ara Jesus Reyes A.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Flexible exporter for grid-like components
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 own set. You could try to implement it in such a way that rewriting it in the future to use fpc features, may become less cumbersome. The fpc development cycle is far slower than ours, and it would mean > 1 year waiting for this feature. Keep the Laz prefix in the base class. My 2 cents. About the name TLazExporter: The base class should probably start with "TCustom" ? 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. Since it is only in trunk, it does not really matter if (even radical) changes are made to the system in the road to the next major release. Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
Thanks. So what is the best way to provide those 100 to 1100 record at least without Dataset calling AfterScroll event? I want to not make any event while scrolling my custom Grid so other connected DB controls change their values otherwise while Im scrolling my custom grid it will cause calling all connected DB controls to update their values. I hope it is more clear now. Regards, Ara -- http://www.fastmail.com - A fast, anti-spam email service. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Flexible exporter for grid-like components
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 plug in other formats. And this is why I think it is crazy that the Lazarus developers went that route. Plus, why is the Grid now burdened with file and exporting/importing functionality. They should have kept those functionalities separate. The same applies for populating a grid from a data file (csv, xml, json etc). And that’s exactly what I did in fpGUI - separate functionality, thus separate classes and units. I think your idea is definitely a step in the right direction. The TStringGrid’s SaveToCSVxxx and LoadFromCSVxxx methods should also be marked deprecated and after one release be removed - replaced by something like what you created. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Flexible exporter for grid-like components
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. +1 I would only suggest to keep the new units to a minimum, or if two units are needed name the grid related code as gridutils. Jesus Reyes A. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
En Fri, 06 May 2016 16:20:41 -0500, Aradeonas escribió: Thanks. So what is the best way to provide those 100 to 1100 record at least without Dataset calling >AfterScroll event? I want to not make any event while scrolling my custom Grid so other connected DB controls change >their values otherwise while Im scrolling my custom grid it will cause calling all connected DB >controls to update their values. I hope it is more clear now. Regards, Ara The easy one is probably to make two independent connections to the database. More elaborated solutions would be for example copy all said records to a memdataset and only connect that to a dbgrid, OR put the records in a non-dataset enabled component, like a TDrawGrid or TStringGrid, browsing that will not trigger any dataset events so other db controls will be unaffected, etc. The problem here is I think synchronizing stuff, you will have a funny time getting the updates to those records into the original source. Jesus Reyes A. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Example of full screen console program anywhere?
How about using the Crt unit? It implements a Turbo Pascal-compatible API under all supported targets and should work fine with terminals. Example: http://pastebin.com/gzhsrv6x On Thu, Apr 28, 2016 at 9:27 PM, Bo Berglund wrote: > On Thu, 28 Apr 2016 15:23:01 +0200, Bo Berglund > wrote: > > I went ahead and created a new Console Application in Lazarus where I > use the same object for controlling the GPIO pins as I did in the GUI > program. > > The Console program just initializes the control object then enters > into a repeat loop reading a key from the user and then interpreting > the key in a case construct for valid commands. > It exits if the q key is pressed. > > When I run this in Lazarus all operates according to plan but as soon > as I try to run it outside of the GUI, for example in a terminal in > Raspbian or in a PuTTY terminal connected by SSH to the RPi literally > nothing works of the stuff that should happen in the repeat loop! > > What I get is the greeting message and then when I press the keys that > should produce the action nothing at all happens including pressing q, > which is the exit code out of the loop and should terminate the > program. > > For some reason it was possible to close it using Ctrl-C, though. > > In Lazarus I use the debug window "Terminal Output" and here > everything planned works fine! > > What a mystery! This is the first time I have encountered such a > difference! > > After some further debugging I found that the keypresses are not even > handled in the repeat loop. It uses this type of construct: > > //Display main screen > Writeln('Controls are:'); > Writeln('p = Toggle 12V SS Power ON/OFF'); > Writeln('w = Toggle WiFi Power feed ON/OFF'); > Writeln('l = Toggle Alarm Lamp ON/OFF'); > Writeln('s = Start SS by sending a 1s pulse'); > Writeln('q = Quit the program and reset the control lines'); > Writeln('Press any key!'); > > //Check input and act on commands > repeat > Read(cKey); > case cKey of > 'p': //SS Power toggle command > ... > until cKey = 'q'; > end; > > I added debug printing to the case sections to see what was sent in > and the answer was NOTHING! > It seems like Read() does not return anything for a simple key press > unlike what happens in the Lazarus debug window. So the program > probably just hangs on the Read(cKey) command, but in Lazarus it does > not so it is impossible to debug... > > Then I tested to use the Enter key and surprise! Now the relays > operate... > > But this should happen exactly when the key is pressed not when Enter > is also pressed later. I use Read() instead of Readln() just in order > to get one single key to process... > > What could be done to fix this? > > > > >-- > >Bo Berglund > >Developer in Sweden > > > -- > Bo Berglund > Developer in Sweden > > > -- > ___ > Lazarus mailing list > Lazarus@lists.lazarus.freepascal.org > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How TDBGrid works
On Friday 06 May 2016 23:20:41 Aradeonas wrote: > Thanks. > > So what is the best way to provide those 100 to 1100 record at least > without Dataset calling AfterScroll event? > I want to not make any event while scrolling my custom Grid so other > connected DB controls change their values otherwise while Im scrolling > my custom grid it will cause calling all connected DB controls to update > their values. > I hope it is more clear now. > If the wanted record is in window of TDataLink.FirstRecord..FirstRecord + BufferCount - 1 you can temporarily switch the record which supplies the field data by setting TDatalink.ActiveRecord which doesn't fire any events. I assume you know that. ;-) See for example the MSEgui functions TGridDatalink.GetDisplay*Buffer(), BeginGridRow() and EndGridRow(). https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/db/msedbedit.pas If the wanted records are anywhere in the dataset you need a dataset with random row data access. TMSEBufDataset supports it, please see the TMSEBufDataset.Current* properties. https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/db/msebufdataset.pas The MSEgui dropdownlist DB-edits use this approach for lookups if Dropdown.OptionsDB odb_directdata is set. A possible workaround could be to call TDataset.DisableControls(), to fetch the needed records and to restore the DB cursor position before calling EnableControls(). I fear it is not efficient and has sideeffects. Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus