This should be a simple question on JasperReports. I'm trying to do a simple counter over the whole report that should increment based on a condition. However, whatever I try, it seems like the counter variable is always being incremented, regardless of the variable expression. My variable's definition properties are below:
Class: Integer
Calculation: Count
Reset type: Report
Increment type: None
Variable Expression: $F{on_target}.doubleValue() >= 0.0
Initial Value: Integer.valueOf(0)
I have a total of 23 rows in the data set, and based on the criteria, the counter should eventually equal 18. I have the variable outputting in the Summary band, with Evaluation Time to Now. However, regardless of the evaluation time, and even setting the Variable Expression to Boolean.valueOf(true == false), the variable's value always ends up as 23.
What simple little thing am I forgetting?
I think I've got it. This makes vaguely no sense, but... (mind you, this is my first time working with Jasper Variables, so it was trial and error).
The Variable Expression isn't quite a Boolean, where a counter type variable isn't incremented if the expression is false, like you'd think. The variable is incremented if there is any value evaluated in the expression. Thus, for me, what ended up working is below:
$F{on_target} >= 0 ? 1 : null
Note the usage of null if the expression should be false.
It makes vague, twisted sense. But is in no way intuitive. Oh well, so it goes...
or in other words:
When you are using the Calculation:Count function of a Jasper-defined Variable you want the Variable Expression to:
resolve to non-null value to increment the counter
resolve to a null value if you do not want to increment the counter
That's why the test listed above works
As well as the setting the variable expression to:
$F{on_target} >= 0 ? 1 : null
Try also setting the initialValueExpression of the variable to 0.
This worked for me:
$F{on_target} >= 0 ? 1 : BigDecimal.ZERO
No initial variable value necessary.
Related
I have an old report with a column that has an expression looking like this:
=IIf(Sum(Fields!projqty.Value)<>0, IIf(Max(Fields!projekttargettime.Value)=1,
(Sum(Fields!projtime.Value+Fields!acwtime.Value)),
(Sum(Fields!projqty.Value)*Fields!targettime.Value)),
(Sum(Fields!projqty.Value)*Fields!targettime.Value))
I dont understand how to read the code and wonder if someone could explain it?
This is called an inline if, or iif().
An inline if basically goes along the lines of:
iif(<test condition>, <value for true>, <value for false>)
For your example, you also have nested iif() statements to work things out.
It goes..
IIf(Sum(Fields!projqty.Value)<>0 - check to see if this sum(Fields!projqty.Value) is not equal to 0
IIf(Max(Fields!projekttargettime.Value)=1 - the first test was true (not equal to 0), so now we want to check if this max(Fields!projekttargettime.Value) is equal to 1
(Sum(Fields!projtime.Value+Fields!acwtime.Value)), - we got here because the sum(Fields!projqty.Value) is not equal to 0 and the max(Fields!projekttargettime.Value) is equal to 1
(Sum(Fields!projqty.Value)*Fields!targettime.Value)), - we got here because the sum(Fields!projqty.Value) is not equal to 0 and the max(Fields!projekttargettime.Value) does not equal 1
(Sum(Fields!projqty.Value)*Fields!targettime.Value)) - and finally, we got here because the original sum(Fields!projqty.Value) is equal to 0. We never check for max(Fields!projekttargettime.Value) as we don't reach that part of the iif()
See here for more information on expressions in SSRS.
The question is simple: Why does this give the wrong answer (0)
IIf(Date()>=#3/16/2018#>=Date()-30,1,0)
While this gives the correct answer (1)
IIf(Date()>=#3/16/2018# AND #3/16/2018#>=Date()-30,1,0)
More specifically, what is Access doing in the first case?
This situation is made even more curious because, when I execute this code, I get an unexpected answer (1)
IIf(Date()<=#3/16/2018#<=Date()-30,1,0)
You can't compound comparisons in Access!
Using your last example, Access first executes the first comparison:
Date()<=#3/16/2018#
That might result in True or False. Let's say it's True
Then, Access evaluates the second comparison:
True <= Date() - 30
(This is since they're processed from left to right, and the first one is true).
This doesn't make much sense, but Access can cast a boolean to a number (-1 = True, 0 = False), and a date too (for example, today = 43186, since dates are defined as the number of days elapsed since 1899-12-30).
That means the second comparison results in:
-1 <= 43186 - 30
And that's certainly true. You also see that if the first comparison is false, the second one will be true nonetheless. Your comparison will pretty much always return true.
Is there any real difference between "IF integer IS INITIAL" and "IF integer = 0" in ABAP? I mean, the initial value in the I type is 0 instead of NULL, so the result is the same, isn't it?
There is no functional difference.
The only difference is that if you ever change the type of the variable you are testing, the meaning might change. E.g. if you change it to a character based type the initial value will be SPACE.
Imagine you've got a while loop with an OR condition of two values. The second value has an increment (++). If the first value is true increment from the second value never seems to occur.
Let's take a look at a piece of code:
bool iterationPassed = false;
while (!iterationPassed || ++retries <= 3)
if(somethingHappened)
iterationPassed = true;
Okay, I'm very aware that this is logical. If the first value is true, there's an OR statement, why would there be a need to check the other value. But in this case, the other value is a result of another step (++) and that step never happened. So I guess incrementing or doing any sort of operation in a complex condition is a very bad practice? Also, is this language specific?
I'm working with LINQ in VB.NET and sometimes I get to a query like
For i = 0 To 10
Dim num = (From n In numbers Where n Mod i = 0 Select n).First()
Next
and then it comes the warning "Using the iteration variable in a lambda expression may have unexpected results. Instead, create a local variable within the loop and assign it the value of the iteration variable."
I know it's not a good practice to use the iteration variable in the lambda expression, because lambda expressions are evaluated only when needed. (This question is about that)
Now my question is, how to suppress this warning in cases where the expression is evaluated in-place, with constructions like First(), Single(), ToList(), etc. (It's only a warning, but i like my code clean.)
(Declaring a local variable and passing the iteration variable to it is an option, but I'm looking for a clean solution.)
In this particular case where the lambda is evaluated immediately, then you can safely eliminate the warning by moving the declaration of the iteration variable outside the for loop.
Dim i = 0
For i = 0 To 10
...
I do want to stress though that this only works if the lambda does not escape the for loop (true for your scenario).
Also here is a detailed link to an article I wrote on this warning (why it exists, how to avoid it, etc ...)
http://blogs.msdn.com/b/jaredpar/archive/2007/07/26/closures-in-vb-part-5-looping.aspx