Strange Wrong Number Output

[Former Community Member]

(If I spell something wrong here, plz forgive me, I don't have the English livecycle programm.)



I have LiveCycle 8.2 ES. In German there is an object called "DecimalField".

Okey, I open a new document, set the number of digits in front of the decimal point (max) to 14, after the decimal point (max) to 2.

Now I look at the preview. I type in 12345678901234,12. Press enter (2 times) and the number written in there is: 12345678901234,119.



Same goes for:

12345678901234,21 -> 12345678901234,211

12345678901234,54 -> 12345678901234,539

12345678901234,22 -> 12345678901234,221

etc.



In other cases it simply changes the last digit so it still has two digits after the decimal point, but one of them is wrong.



Somehow this really bugs me, since I have a greater document with lots of those fields... so now the question, how can I get these to work correctly???



I tried some things, like giving an "pattern" in the "example". But things seemed to get even worse.



Thanx already for your help.



PS.: If you think you could help me if I post the xml-source here, I will do so...



EDIT: PPS.: Am I the only one with this problem or is this some kind of standard bug?



EDIT: Numeric Fields have the same problem. (Thought they worked correctly first and tried to limit it with javascripts. Output differences are the same.)

[Thomas_McConnac]

I would say that the pattern the field is using is wrong.



If all numbers must be 14 digits, followed by a decimal point and then another 2 digits the pattern should be:



num{99999999999999.99}



If it can be a maximum of 14 use



num{zzzzzzzzzzzzz9.99}



9 forces there to be a character, so you will get 00000000000000,00 but z allows a blank character so you can get 0.00.



Check all of the validation pattern tabs to make sure they are all the same.



Hope this helps,



Tom

[Former Community Member]

Thanx, but don't think so.



To the upper field I didn't give any pattern. But normally I use the following one:

num{zzzzzzzzzzzzz9.zz}

(Should be allright, if the last two digits are optional for input. Thought about .ZZ too, but I am not sure if I'll do so.)



There is no binding etc. It is a complete new document with only one field so it normally shouldn't have any extraordinary other patterns or validations.



It's also not like, it wouldn't accept my number (nor do any validation errors occur)... the number just changes after input (and confirmation = click something else) and most times gets an extra digit at the end of the line...

Also this doesn't occur everytime. Though about 8 of 10 times when I really use all digits, 14 pre comma and 2 after comma.

In lower fields (think less then 10 pre comma digits) it also doesn't seem to occur.



(Another little question about the xml sheme, xsd-elements. Is 3d2 are num{z.zz} or num{zzz.zz} ones? [since this sometimes changes from language to language, I wanna make sure I don't do any mistakes :) ] But this one is not so important to me...)

[Thomas_McConnac]

OK, just had a play around.



Make sure it is set the same in the edit tab.



I have mine set in Display, Edit and Validation and it is working fine. But when it was in Display and Validation it was adding on the extra digit when I was inside the field (disappeared when I left.)



I have no idea about the 3d2 thing though, sorry.



Tom

[Former Community Member]

Thanx that worked :)



I just had given a pattern in display, since I thought it would work as the "local scheme"(? lanugage?) which is automatically transfered to Edit, Validation etc.



That really gave me some hard time, since I am editing some documents and I didn't know what my predecessor might have changed.

[Former Community Member]

I thought I got rid of this problem...

But it appears again. Wrong Numbers are striking back ;(

(This time I have already given the patterns, so this can't be the solution :( )



Again, 14 pre comma and 2 after comma digits.



The Number 90000000000000,01 can't be written!!!

After writing it in 90000000000000,02 appears.

Same for:



90000000000000,04 -> 90000000000000,05

90000000000000,07 -> 90000000000000,06

80000000000000,01 -> 80000000000000,02



Though it might have something to do with the lenghts of the number and the last digit 70000000000000,01 works perfectly. And the worst is: after leaving the field the number stays incorrect.



Would be glad if someone could help me. Is there a bugfix or anything like that???

[Former Community Member]

Anyone knows how I could contact Adobe (Live Cycle Team) the best to ask for a bugfix?



Thanx for your answer already...

[Former Community Member]

Does really noone know, why the numbers change or what to do against it?

[Former Community Member]

Can you post your form to livecycle8@gmail.com and I will have a look. Make sure to indicate the steps required to duplicate the issue.

[Former Community Member]

Got feedback that the numbers are out of range :(

2^31 seemed to be the largest possible number.



But now, FINALLY, FIIIIIIIIIIIIINALLY I made my way around that problem.



Solution: I do make a Textfield and give the pattern num{zzzzzzzzzzzzz9.zz} in each of the fields. (I used this method to work arround other problems already and I am not sure, why I didn't try it in this case.)



To ensure the output number is correct I made a little script for another textfield to get the number. (raw.Value = raw.Value; the patterned decimalfield gave out wrong numbers again in that case)

Works nearly perfectly... nearly...



Only thing I couldn't fix this time: they change the , to a . when transfering. (Though this is a minor problem in my case... but why does it do this? I'd be interested in why it changes the strings like that if anybody knows.) And calculations are still wrong. (But lucky again, I don't have to do calculations.)



(And still I think this method is UGLY, but works at least better than doing nothing.)



Lisa