Re: [Lazarus] Example of full screen console program anywhere?

[Kostas Michalopoulos]

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

[Jesus Reyes A.]

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] Flexible exporter for grid-like components

[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.



+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] Flexible exporter for grid-like components

[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 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] How TDBGrid works

[Aradeonas]

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

[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 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

[Jesus Reyes A.]

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] How TDBGrid works

[Aradeonas]

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

[Jesus Reyes A.]

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

[Aradeonas]

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] Flexible exporter for grid-like components

[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 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 

Re: [Lazarus] How TDBGrid works

[Aradeonas]

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