Reuse Global Variables

I have a two column report that uses several tables. There is an Aggregation of the table values in the footer row of each table. I have added a grid at the end of the report where I want to be able to reuse the table totals to generate a couple of different summaries and calculate some percentages. I have been able to use the global variables I set up to capture the totals once, but when I try to use them a second time, I get a value of 0.00.

I have tried <var myGlobalVariable = .00;> and variations of <reportContext.setPersistentGlobalVariable("myGlobalVariable", .00);> in the Report/Initialize Method. I have tried <myGlobalVariable= row["AggTotRetain"];> and variations of <reportContext.setPersistentGlobalVariable("myGlobalVariable",row["AggTotRetain"]);> in the Cell/OnCreate method but I haven't gotten anything to give me the correct results. Can someone point me in the right direction?
BIRT 2.3.2

Find more posts tagged with

Comments

mwilliams

Hi jasheets,

Can you set up a quick example of this with the sample database so I can see it run? Thanks.

UtahJerry

Here is a sample of what I am trying to do. This is the same Multiple Column report I was having the print issues with. If you still have that, you have the actual report and data as well.

mwilliams

jasheets,

Here you go. This should help. I believe the PGVs only deal with strings, so if you change your value to a string and then use the parseFloat() function to return it to a float value, you won't have any errors. Attached is the sample report with the appropriate changes made.

UtahJerry

Perfect! I was getting Java Heap: OutOfMemory errors earlier and one of the Eclipse developers told me it was because I was using this.getValue which also converts the value to string. It should have occurred to me that getPGV could be giving me the same results.

This might be a good sample to add to DevShare. Thanks! Jerry

mwilliams

Jerry,

No problem. If you'd like to add this to the devShare, feel free. If not, I can easily make a nice colorful example to place out there. Let me know.

UtahJerry

Michael, I still haven't been able to get this to work on my 'live' data. I must be overlooking something. I have attached a zip file that contains the 'live' report converted to run from CSV data and the CSV files it uses. I have also included the working sample you sent me and the report from the Actuate erdPro version of the report that I am trying to recreate in BIRT. It appears to work for the 'Net Retainage' calculation, but not for any of the others. If you have a chance, would you look at it and see what I am overlooking?

Thanks,
Jerry

mwilliams

Jerry,

I believe the reason behind this issue is that the data bindings you're using are bound to the outer grid, not the inner grid. For this reason, the bindings are created before the aggregation values you're trying to use, so they have not data available. You can get around this by using dynamic text items to display the values. You would have to do your currency formatting in the code though. So, in dynamic text elements rather than data elements put code like the following:

df = new Packages.java.text.DecimalFormat("$#,###.00");
df.format(parseFloat(reportContext.getPersistentGlobalVariable("gvTotAwards")) + parseFloat(reportContext.getPersistentGlobalVariable("gvTotChgOrder")));

I was able to get this to work in your report. Let me know if you have any other questions.

UtahJerry

That solved the problem everywhere except the two cells in the lower left Grid labelled 'Adjusted Contract Value' and the cells labelled 'Contract Balance' and 'Contractor Balance'. I used the exact same code you used to calculate the 'Adjusted Contract Value' in the Grid above. The last two cells are the 'Adjusted Contract Value' minus 'Total Paid...', so I again used the same code for the 'Adjusted Contract Value' portion of the formula. In all 4 cells, I get a square (which I assume is a null or NaN). I suspect, there is another 'timing' issue since the code works in one Grid, but not the other one. I'm still working on it, but thought you might have an idea since you've already looked at the timing of the data availability.