I know fpreport is part of FPC, but the main wishes are for the designer:
fpreport is a fairly good approach to creating reports, but it is currently not possible to create more complex reports. (I'll explain that later).
(At least not with the designer)
After spending some time trying, I have now put together a 'wish list'. Unfortunately, I don't really get along with the source code because my knowledge is not sufficient.
Since I create reports with the designer and do not want large unit dependencies, the main points relate to the designer.
1.
The detail header and detail footer must be able to be output on every page of the report. Otherwise it is currently not possible to create meaningful invoices.
Background: In the case of an invoice over several pages, the running total must be output under the details, on the following page the transfer (according to the detailed headings) above the first position.
2.
There should be a way to check in the report whether the currently output page is the last page with detailed data.
A check like PageNo = PageCount is not sufficient here!
Background: This is necessary to control the totals.
3.
In the data editor you can define the field names for csv. It should also be possible to define the type and size here. (As with json).
In addition, a selection may be useful (checkbox) to 'Supress first line'.
Background: Longer text fields (at least from csv) are cut off after 256 characters.
This results from defaultsize when reading csv.
4.
Reports with json data cannot be generated with the designer. An access violation occurs.
4a.
In the attached sample report I use csv data out of 4 files. However, this should also be possible with a single structured json file.
5.
The graphic is saved several times in the report, although it is always the same. Optionally, you should only be able to save the path to the graphic (select link or include).
Background: It happens that a report file is inflated unnecessarily.
6.
Transparency should be supported with png, SVG would generally also be desirable.
7.
Sums must be able to be formed, i.e. values should be assignable to the variables.
This may require simple scripting (well solved in Lazreport).
7a.
How can variables be used? I don't get a solution.
8.
Elements and bands should be handled with copy / paste (cross-report).
9.
The report designer is very susceptible to incorrect entries and you then accidentally close it. All entries are then lost.
10.
Texts from MySQL are not read correctly if they come from text, tiny text, medium text or long text fields. Here only VARCHAR () seems to be possible for text.
Not that bad if you take this into account, but it is still a mistake.
I am still attaching my current test report.
Attention: The report designer must be copied into the folder, otherwise the paths are incorrect (I have deleted the path information in the report).
My opinion at the moment on fpReport:
There are still some important things that should be done.
Then, however, a very good, really useful reporter for Lazarus would finally be a reality.
It would be unfortunate if fpReport were given the same fate as the other players.
Unfortunately, there is no other way to continue using lazreport and to deal with its weaknesses ...
FpReport can already be used very well for simple reports.
I could also imagine a function for label printing, it would even be relatively simple:
A dialog asks which label should be used for printing. 'Blank details are inserted accordingly' ...
I actually do this currently with empty data records, since the query takes place in the program before data preparation.
In general, I cannot generate the reports in my units, as this means that the flexibility that is needed will be lost.
I hope someone is willing to help with making fpreport the best reporter for FPC
and wish you all a good and successful 2020!
Recent
