I've been editing forms using Livecycle. A validation pattern within one of the fields is becoming jumbled. It's supposed to show a numeric code when too many numbers are typed into the field so the employee knows too many digits were typed and can correct the error. The validation pattern is reading the too many digit error, but has also started not accepting certain patterns of numbers. I've tried several different things to correct this issue. What can be done? I know deleting the field will take care of it, but we would ultimately like the validation pattern to work correctly. I was not the one who created the forms originally and am an amateur when it comes to Livecycle. I'm not even 100% certain how to add a validation pattern to a new field if I were to delete it and start fresh. What can I do?
I've just been told by our support that it's something with the validation pattern. I am truly amateur when it comes to LiveCycle. We've looked at the XML code and cannot find where there is one. 2147483647 appears in the field when the entry is too long or when it doesn't like the sequence.
Does the change to the field occur while the user is typing in numbers, after they exit the field, or after clicking a button to submit the form? I ask because that could help determine where the validation is occurring. It might not be part of the XML for the text/number field at all.
For instance, here's an example of a field that has a ssn validation pattern, a button that checks to ensure the number entered is divisible by 9, and a script on the change event to be sure it stops at 9 characters. Since each part of that takes place at a different point, the two scripts and pattern are spread out. I included the XML and where they came from.
Can you show the script that is in the exit event for that field then?
If you're curious about the significance of your number: 2,147,483,647 is the highest integer value available for a 32-bit integer.
I've pasted the XML code below. Please give me any feedback you can as I haven't had any sort of formal training with this program.
It is the account number field that I'm having the trouble with.
Once I set up a field otherwise identical to yours, I can replicate the issue by entering an integer that is too high for the numeric field to handle. If I change the data format to Float, the field will hold larger numbers. (Select the field. Object tab, Binding subtab.)
Edit: Removed unnecessary information.
This does appear to work, however, the 32-bit integer no longer appears when the number contains too many digits. We would like it to still work in that instance.