1 person found this helpful
What you're seeing is not a bug, it's expected. You assume parseInt will always go with a base-10 conversion - however, it looks at the string to decided what is best if no base variable is supplied. When there is a leading zero, it assumes a binary or hex string and then will stop when it hits an invalid character.
If you want to force a base-10 conversion no matter what, simply specify it:
Thanks for the explanation. I was not aware of this.
Is there a reason why this works differently in other Adobe apps? Running parseInt('09') results in '9' when run through ExtendScript for the CSX suite.
Thanks for clarifying that for me, and the link is very helpful. I was not aware that I had not been using parseInt properly. The code I am using may have originated in an ExtendScript script, and, having worked properly there, I had naturally assumed it would be fine here. I shall need to be more careful when repurposing code from ExtendScript into Acrobat.
For reference, is there any documentation noting where ExtendScript is not ECMAScript compliant?
No, and I mis-stated myself.