calculating values in fpreport

[MacWomble]

Does anyone know how to define sums or other calculations in fpreport designer ? 

There must be a way to do page sum, report sum etc. e.g. for invoices. Is this possible and how to do?

[Pascal]

I haven't used designer so far but in code it's possible: see rptnestedgroups.pp in packages/fcl-report/demos.

Add an expression variable and set the reset expression to that of the group:

Code: Pascal  [Select][+][-]

1. rpt.Variables.AddExprVariable('grp1region_sum_population', 'sum(StrToFloat(population))', rtFloat, GroupHeader1Region);

Use it in memo:

Code: Pascal  [Select][+][-]

1. Memo.Text := '[formatfloat(''#,##0.0'',StrToFloat(population)/grp1region_sum_population*100)] %';

This should be possible in designer, too.

[af0815]

IMHO there are some features actual in the designer and you can not do the same thing like in code.

More people should try the designer and test it :-) before make a post with 'This should be possible...'. No actual it is IMHO not possible - and this was the question.

[Pascal]

I am just investigating this topic. The appropriate functions seems to be there in "Report/Variables...".
I'll try to build a simple sample report.

[af0815]

Thank you, for your investigatement.

Please try it with designer only. 

[MacWomble]

More people should try the designer and test it :-) ...

Yeah, that would be great!

@Pascal: Great to have some help here ! Thank You !

[Pascal]

Will be a bunch of work!
Just realized that all my old samples with plenty of aggregations and grouping do not work anymore with current version.

[af0815]

BTW. when i mean - some features - it is sarcastic. Actual i am diving back to the fpc part of fpreport and look if it is bugfree or not.

[af0815]

With the decision of MvC here (https://bugs.freepascal.org/view.php?id=36525) ist looks impossible to use the fpexpression in the fpreport for calculating of aggregations and grouping on an non english configured system. On a german system the decimal seperator is a comma not a dot. If data is sent to fpexpression it must be converted to a non system standard value to be aggregated. The same problem i have found in the tests of fpreport, because the Formatsettings sometimes not handled ( https://bugs.freepascal.org/view.php?id=36519 ). I think the fpreport was not well testet with other Formatsettings.

This made the things bad twice.

[Pascal]

Never mind, i will spend some time on this. But i have to study the changes of the last two years, as my last active development on fpreport was back in 2017. So please be patient or submit patches.
I will first make the nestedgroup demo work again, as this is the most complex one.

[af0815]

BTW: some if the tests of fpreport did not work too. Time is no problem, i will understand more of the internal working. At christmas it was possible for me to dive in a little, it is a hobby for me.

[wp]

With the decision of MvC here (https://bugs.freepascal.org/view.php?id=36525) ist looks impossible to use the fpexpression in the fpreport for calculating of aggregations and grouping on an non english configured system. On a german system the decimal seperator is a comma not a dot. If data is sent to fpexpression it must be converted to a non system standard value to be aggregated. The same problem i have found in the tests of fpreport, because the Formatsettings sometimes not handled

Looking in the fcl-report/src directory I found a unit fprexprpars which is more or less a copy of the standard fpexprpars unit (note the additional "r" behind the "fp"); this was probably needed to provide dedicated adjustments of the parser for the report engine which should not be used in the standard parser. Maybe MvC changes his mind when the patch of the bug report is modified to apply to fprexprpars, not to fpexprpars?

[Pascal]

With the decision of MvC here (https://bugs.freepascal.org/view.php?id=36525) ist looks impossible to use the fpexpression in the fpreport for calculating of aggregations and grouping on an non english configured system. On a german system the decimal seperator is a comma not a dot. If data is sent to fpexpression it must be converted to a non system standard value to be aggregated. The same problem i have found in the tests of fpreport, because the Formatsettings sometimes not handled

Looking in the fcl-report/src directory I found a unit fprexprpars which is more or less a copy of the standard fpexprpars unit (note the additional "r" behind the "fp"); this was probably needed to provide dedicated adjustments of the parser for the report engine which should not be used in the standard parser. Maybe MvC changes his mind when the patch of the bug report is modified to apply to fprexprpars, not to fpexprpars?

Can't find it! Did you mix it up with fprepexprpars, which is used for fpc versions below 030101?

[MacWomble]

fprepexprpars.pp is in my fpreport directory too ...

[wp]

With the decision of MvC here (https://bugs.freepascal.org/view.php?id=36525) ist looks impossible to use the fpexpression in the fpreport for calculating of aggregations and grouping on an non english configured system. On a german system the decimal seperator is a comma not a dot. If data is sent to fpexpression it must be converted to a non system standard value to be aggregated. The same problem i have found in the tests of fpreport, because the Formatsettings sometimes not handled

Looking in the fcl-report/src directory I found a unit fprexprpars which is more or less a copy of the standard fpexprpars unit (note the additional "r" behind the "fp"); this was probably needed to provide dedicated adjustments of the parser for the report engine which should not be used in the standard parser. Maybe MvC changes his mind when the patch of the bug report is modified to apply to fprexprpars, not to fpexprpars?

Can't find it! Did you mix it up with fprepexprpars, which is used for fpc versions below 030101?

It is in the official sources of fpc trunk: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-report/src/fprepexprpars.pp?view=log. If it is not needed any more it should be removed.