Annoying addField problem with derived fieldname

[Murgle]

I am attempting to generate a series of fields using addField, which takes a predefined suffix (e.g. 't') and concatenates this with a full stop (or period '.') followed by a numeric value (e.g. 153) which has been entered in a text box by the user.
e.g.

var box1 = this.addField(("t" + "." + numval), "text", 0, [0, 0, 50, 50]);

If I try to concatenate the three elements separately then the addField variable is undefined - this is also the case if I try to concatenate 't.' with the number, even when the value of the number field is set to string.

If the value in the text box is entered as .153, then it works - however the value is seen as a decimal, and a leading zero is added to it, even if the value is toString. This means I get a fieldname of t0.153 when i want t.153. I tried using a script to remove leading zero's, but it seems when the concatenation takes place that the zero is added back on again.

As I write I don't have my full script to hand, but will post it when I can - grateful for any suggestions



"If toast always lands butter-side down, and cats always land on their feet, what happens if you strap toast on the back of a cat and drop it?"
- Steven Wright

 

[Murgle]

Hmmm, looks like I might be wasting my time - although you can legitimately name a field t.153 when creating it manually, it would appear that you can not do this when creating the field using addField - the variable always errors as 'not defined'. Call it t0.153 however and it works - pity that's not the fieldname I want tho.


"If toast always lands butter-side down, and cats always land on their feet, what happens if you strap toast on the back of a cat and drop it?"
- Steven Wright

 

[samaba]

You are running into a Parent/Child format that Acrobat has already reserved. . .

You can name your original field what ever you wish, but when you start using the full stop (.) then Acrobat thinks it is a child field for relational data.

Try adding a field, then using the right click "Create Multiple Copies" to see how Acrobat uses this naming convention.

Probably not what you were wanting to hear. . .

 

[Murgle]

samaba
Thanks for that, I was afraid this might be a reserved naming convention, but couldn't understand why it would allow t0.153 and not t.153? - I actually use it to generate numbered fields in a separate register document, then import fdf files of each individual document on page open event. As it stands I have to renumber the parent field in each document so that it has the child extension which matches it's place in the register e.g.

A new form is raised and emailed to me
I allocate the next available number in the register file e.g. 153 - this line in the register has 10 fields all with extension .153
I renumber the corresponding data fields in the form with the correct extension - a change in the form data triggers an export to an FDF file with a predefined name.
I add the instruction to import this fdf file to the page open event.

I would have preferred to remove the need to edit field names manually in the original form, as this requires someone with full access to maintain it - it would be better to just have this access for the register as there is little damage that could be done here. Ah well.

"If toast always lands butter-side down, and cats always land on their feet, what happens if you strap toast on the back of a cat and drop it?"
- Steven Wright