Format numeric field to neither add or remove zero after radix

[Jost0]

Hi!

I've got a form here with a bunch (> 100) decimal fields, most of them set to 3 leading and 1 trailing digits (everything else is at its default value).

Now I want to create display patterns to simply display in the same way they where entered. The problem is, that a single trailing zero is either added or removed, but never simply taken from the user input. For example:

If both the display and edit patterns are set to num{zz9.9}:

• User enters 123 - display is 123.0 <- wrong
• User enters 123.0 - display is 123.0 <- correct
• User enters 123.4 - display is 123.4 <- correct

If both the display and edit patterns are set to num{zz9.z}:

• User enters 123 - display is 123 <- correct
• User enters 123.0 - display is 123 <- wrong
• User enters 123.4 - display is 123.4 <- correct

I've also tried several other pattern combinations, but nothing seems to work. Any idea on how to repair this behaviour? Changing the field type from decimal to something else would be possible, but much work (even when working directly on the xml-version of the files, as there are about 30 fragments in separate files that would need to be edited.)

Kind regards,

Jost

[radzmar]

Hi,

use the pattern num{zz9.8} if the decimal places are optional.

[Jost0]

Hi radzmar,

thanks for your answer.

Specifiying one or both patterns (and some other combinations)  to num{zz9.8} yields the same results as when using num{zz9.z}... I can't find any explanation of the character "8" in the documentation, although I remember having seen it there some time ago.

Any idea what goes wrong/if there is another solution?

Regards,

Jost

[radzmar]

Hi,

the meaning of the '8'-pattern is described in the XFA specification.

http://partners.adobe.com/public/developer/en/xml/xfa_spec_3_3.pdf#page=1177

[Jost0]

Hi again,

sorry for the late reply. For some reason, the pattern num{zz9.8} is accepted as a valid pattern, but does not function - the results are the same as when using num{zz9.z}.

Steps to reproduce:

Create an empty form with a decimal field on it, set its maximum leading digits to 3, the maximum trailing digits to 1 and set the display and/or edit pattern to num

Maybe this is a bug in LiveCycle (v9.0.0.2 Build somewhen in 2010)? I take the fact that the pattern is accepted as a hint to this... Either way, I'm quite sick of this software and its bugs. This is not the first one I discovered, and almost all the bugs I've discovered so far are major bugs, rendering this thing nearly impossible to use. I though paying a couple hundret € for a software would get me a relatively bug-free experience (or at least patches within a reasonable time), but it does not seem to be this way. Almost any open source software with this level of acceptance is better maintained than LiveCycle.

[radzmar]

Hi,

I'm not sure what's wrong at your end.

For me it's working fine.

Here's an example for you to test.

https://acrobat.com/#d=FylZw7eUhoFfj7it6iHoXg

[Jost0]

The problem remains the same in your example:

• User enters 123 - display is 123 <- correct
• User enters 123.0 - display is 123 <- wrong
• User enters 123.4 - display is 123,4 <- correct
• User enters 123,4 - display is 123,4 <- correct

This behaviour is the same in Acrobat X Pro 10.1.3 (Windows 7 Professional), Adobe Reader 9.5.1 (Ubuntu 12.04) and LiveCycle 9.0.0.2 (Win 7 Prof., probably using the Acrobat Pro 10.1.3 Installation). So this happens on two different Systems, with different Versions of Acrobat...

I'm now dropping this, as it seems to be a waste of time to get this behaviour right.

[DanCondonJones]

It sounds to me like the best solution is to make it a free text field rather than a number field - and then either convert it to a number on the fly as and when you want to use it or have a hidden Number field next to it that automatically gets populated with the numerical value.