Faulty variable calculation when using resetType None

[tcleenewerck]

When a counter is created that uses the previous value of a variable, that its result is not correct because the expression of this variable is executed twice.

Two counters have been created.

• myCounter1 uses the previous value of the variable to incrementally compute the sum and resetType None
• myCounter2 uses the SUM calculation method and a resetType Report

The first counter is incorrect.
The second counter is correct.

Note that when the resetType of myCounter1 is set to Report than the calculation is correct.

If you debug the code, you'll notice that the expression of a variable is computed multiple times causing myCounter1 to be incremented twice for each record.

An example report has been created with a csv data set, an adaptor and a simple jrxml report.

Archief.zip

[teodord]

Why do you think resetType should be None for your myCounter1 variable?

Thanks,
Teodor

[tcleenewerck]

First I think 'none' should simply work the same way as other resetType, meaning that they are computed once.

Second because we are also using variables that are accessed in group bands. In Issue #386 we learned that resetType is important to have correctly refreshed/updated variables. We used resetType Report but that doesn't work for group bands. Hence we opted for 'None' because then the variables are always computed correctly with the current record. As such we can use the variables anywhere we want. That makes the use of variables a lot easier. Especially because we use the same variables across detail and group bands.

[teodord]

It appears that resetType=None variables are both "initialized" and also "calculated", which would explain why they get incremented twice. We'll investigate more, but not sure if anything would change since this code is in a sensitive area of the engine.
I would still encourage you to avoid using such self-incrementing techniques as these are not something we would recommend.

Thank you,
Teodor

[tcleenewerck]

Hi Teodor

Thank you for looking into this. I hope that this can be resolved. The fact that variable computations are performed multiple times is not ideal the input values (fields and variables) remain the same and thus the result of the computation is the same. As such the outcome is predictive and it is easy to use and learn the product.

I always considered variables to be some kind of a derived field, an extension of the original dataset. We are using variables all the time to compute derived data based on other variables, fields and yes also based on the previous value of a variable. The computations that are build in aren't always sufficient as you can imagine. It is a very convenient, ui friendly and reliable way of extending and manipulating data in a report. It is one of the most important features.

Thomas

p.s. You often ask us what we are doing. If would be happy to show you what we are working on and how we use jasperreports.

[teodord]

p.s. You often ask us what we are doing. If would be happy to show you what we are working on and how we use jasperreports.

Please reach me at teodord@users.sourceforge.net.

Thank you,
Teodor

[teodord]

It is probably unlikely that we are going to change how resetType=None variables are working, because there would be plenty of regressions even because people rely on it working the way it does, even if it might seem wrong.
I still think you need to consider writing custom java code for the special variables you need, either in the form of scriptlets or custom "incremeterFactoryClass" that you can attach to a variable definition.

I hope this helps.
Teodor

[tcleenewerck]

Hi Teodor

I understand that a lot of regressions might occur and that there might be people relying on that behavior. I usually tackle that this by introducing a new option/feature that works as intended. It is the only way to move forward otherwise we get stuck with decisions that have been made years ago.

It would be a big improvement to the jasper report library as it solves a problem and also offers a simpler execution model for users to learn and use. So would you consider adding a new resetType?

Adding scriptlets and a custom incremeterFactoryClass is something that involves a lot more programming skills and makes jasper report deployment much more difficult.

Thomas