mctozzy
-
Posts
4 -
Joined
-
Last visited
Content Type
Profiles
Forum
Events
Featured Visualizations
Knowledge Base
Documentation (PDF Downloads)
Blog
Documentation (Test Area)
Documentation
Dr. Jaspersoft Webinar Series
Downloads
Everything posted by mctozzy
-
Thanks for the explanation. By creating a second system variable, I assume you meant this: (using "pseudodefs") $V{RunningBal} := sum($F{Amount}) and $V{Balance} := system($V{RunningBal}+$P{InitialVal}) Then using $V{Balance} in the report? I can see that would work, but I don't really understand why there isn't a more natural way to prime a variable, without having to resort to this or use scriptlets. Why not extend the meaning of InitialValueExpression to actually prime the variable? Is this worthy of an RFE? Cheers, Milt
-
I saw somebody complained about this in the old forum, but no answer was provided. The entry of a parameter value off the keyboard for a BigDecimal type doesn't seem to work. It's taking whatever's in the default field regardless. Is this a bug?
-
I seem to be having a problem with initial values for Variables. What I want to do is create a running balance value, so I have a variable with Calc type Sum, Reset type = Report, Increment=none. I have a variable expression such as $F{Amount}. This works correctly, except for one thing. I want to prime the value of the variable, so that it starts off with an "Opening Balance" so to speak. The initialValueExpression doesn't seem to work in the way I would have expected. No matter what I do, the initial value is always zero. Thanks, Milt.
