novakv

Also, there exists a question on this at http://community.jaspersoft.com/questions/535813/no-such-field-exceptions, still with DEBUG level at that time. And here is the fixed chartConstantsBean.xml.

Changed Assigned User from - to @User_306070 Here is a patch that fixes the problem for 6.0.4 release. The fix restores dependent elements later at the and of JRBaseFiller constructor, namely in initBands(). Anyway please do not use this patch for distribution and fix it properly. This is just a hotfix and does not fix the real problem - incorrect order of JRBaseFiller initialization.

Changed Severity from Minor to Major System Message

Hello everybody Have anyone seen this error? When a text field in the detail overflows with three dots, then these dots are repeated for all succeeding empty text fields below. We can reproduce this in version 3.7.1 and 3.7.6. Is this a known bug? thanks Vit

Hi, If our users want to select grouping fields in their reports, we need to somehow dynamically change grouping settings in compiled templates. Simple and intuitive solution would be: $F{$P{field1}} However, this solution doesn't work. Another solution would be more complicated and it looks like this: $P{REPORT_SCRIPTLET}.getFieldValue($P{field1}) Unfortunately, this doesn´t work either - particularly in the Group Expression, and the reason is that it returns the same old and new value. There is no way how the scriptlet could now which value to return. The sheet anchor can be found in how to set custom group parameter, dynamic group expression and How to set the field used for a group by parameter They all recommend to write a new scriptlet, that analyzes stacktrace and depending on it, returns different values for the filed. This might be working with current version, but it is very bad idea for a long time project. It means that one day, all the reports would stop working without a warning and would need to be repaired. So this is not a solution either. My question is how difficult would be to get back to the first solution - clean and simple? Thanks Vit

We have recently decided to use Groovy in our reports. Scripting in reports is very exciting feature, that can definitely solve many customization needs of users. Anyway, we found out very soon, that there are some limitations (as there always are some:) - Groovy version 1.5.5 - No closures alowed - Only expressions alowed We started with simple task of building full name from $F{FIRST_NAME}, $F{MIDDLE_NAME} and $F{LAST_NAME}, where any of these can have null value. The only way to solve this is to use consecutive elvis operators ?:. This is possible for names with two parts, but who has the courage to do this with 3, 4 or more parts? Or if the number is unknown? Look at the code snippets we found out. Maybe there is another simple solution, we didn't find - if anyone knows, please help. Also if anyone found old documentation on Groovy 1.5, this one is hard to find. Anyway, is there any chance to ease groovy support? Most useful would be upgrading groovy compiler and allowing closures. Thanks for help. Code:// Using elvis operator($F{FIRST_NAME} == null ? "" : $F{FIRST_NAME}) + ($F{MIDDLE_NAME} == null ? "" : " " + $F{MIDDLE_NAME}) + ($F{LAST_NAME} == null ? "" : " " + $F{LAST_NAME})// Going beyond simple expressiondef names = [$F{FIRST_NAME}, $F{MIDDLE_NAME}, $F{LAST_NAME}];while (names.contains(null)) { names.remove(null);}return names.join(' ');// groovy 1.5 using closure([$F{FIRST_NAME}, $F{MIDDLE_NAME}, $F{LAST_NAME}].findAll{it != null}.join(' ')// groovy 1.7([$F{FIRST_NAME}, $F{MIDDLE_NAME}, $F{LAST_NAME}] - null).join(' ')

When translating iReport into czech, we encountered lots of strings, that do not use message bundles. If we report these as bugs, is it ok to report more then one string as a single bug? Or its better to divide them into individual reports? There are about tens of these bugs. Thank you for help.