Report designer - Invalid number format

There appears to be a regression in the report designer. It is producing spurious errors when selecting a number format.

Manually entering or modifying a pattern using the ‘Format:’ box gives the error “Invalid number format (see DecimalFormat javadoc for info).”, even if the format is valid.

To reproduce:

  1. Add some text within a table
  2. Press the number button in the format tab
  3. Enter or modify any pattern using the ‘Format:’ box
  4. With the cursor focus still in the format box, click anywhere in the main view
  5. Popup error “Invalid number format (see DecimalFormat javadoc for info).”, even if the format is valid.
  6. The updated format string is not saved.

This issue appears to be specific to tables. If the element being modified is within a table, the error will occur regardless of where in the main view is clicked. This issue will also occur if the element being modified is not within a table but a table is clicked (though I suspect this is due to the bug with properties being mistakenly copied to the next selected element).

Selecting an example pattern does not produce the error (but modifying it or manually entering a pattern that happens to match one of the examples will).

If you can get the pattern saved the report will work as expected.


  1. Take the focus away from the "Format: " box before clicking the main view. Clicking in the “String for Null:” box works, as does switching to the “Color”, “Font” or “Keys” tabs or selecting any focusable component in the Document Inspector.
  2. Press enter to save the updated pattern before clicking in the main view. The error will still be produced, but at least the pattern is saved.

Ignition version 7.5.2 (b1146)
Reporting module version 1.5.0 (b145)

In addition, entering an empty format string results in Java running out of heap space.

Thanks for reporting this issue, I will pass it on to the developers.

As another workaround, you can the Tab key after changing the format, and it will save the pattern change without error.

Thanks James, that’s a much better workaround.

This appears to be fixed in 7.5.5.