Form Fields duplication issue

[atkin31]

I have A TON of form fields that need to be created, across 30 pages, that need to be able to be calculated.  When I create "multiple copies", it shows up in the same page and is a PAIN to try to cut and reinsert onto the next page.  When I "duplicate across page" the new lable adds a "#" to the new field name AND NOW it can not be calculated.  I don't know javascript and I don't want to be sold a some product.  Adobe is hitting my pockets way too hard for this level of difficulty. Please assist.

[Bernd Alheit]

Change the field names after the use of "duplicate across page". 

[ls_rbls]

Hi,

That is not the correct workflow to handle the bulk of duplicated fields.

If you need the fields to be copied exactly as they are, without manually renaming fields one-by-one or without using JavaScript scripting,  it is just easier to open the Left Hand Pane(LHP).

Select  the Thumbnail icon to switch to the Thumbnail View.

=> A list of all the pages in that document will be displayed as thumbnails in that navigational pane.

=> You must hover the mouse pointer over the  desired thumbnail page that you want to duplicate.

=> Press the CTRL key on your keyboard, and keep it pressed as you left-click on the desired thumbnail with the mouse pointing device

=> keep the mouse left button pressed while dragging and dropping the tumbnail out (up or down, for example).

=> As you perform this mouse and keyboard gesture, you'll notice that the thumbnail will turn blue in color to indicate that it is selected

=> release the CTRL key and the left mouse button and that entire page will be copied exactly as the original.

=> After the duplicate action executes you may reposition the duplicated page in the order that you need it in the document using the "Organize Pages" tool.

See if this works for you.

[atkin31]

Thanks for the reply.  Duplicating a page from the thumbnail also duplicates form field names. This means any input on the first page, also inputs on the second page, in the same field, with the same name.  It adds a "#" symbol which can not be calculated.  As I shared in my first post, I need to caluculate form fields independent of each page.  It's alot of fields.  Any other suggestions?

[ls_rbls]

++EDITED REPLY,

I don't understand why you keep emphasizing about the hash pound symbol not letting you calculate.

That symbol is normal with duplicated field objects, specifically with duplicating pages via Thumbnail view, or by manually copying and pasting, or duplicating accross pages methods.

The method that I shared is entirely different from using the "Create Multiple Copies..." action.

In contrast with creating multiple copies, duplicating a page via Thumbnail view is a visual aid for the user to identify which objects were copied as you navigate through the Preview pane while peforming editing actions with the Prepare Form tool.

This field naming convention has nothing to do with calculations. 

If, on the other hand, you were using a JavaScript script to perform calculations it should have no impact unless, of course, you are manually adding the "#0", "#1" symbol (as shown in the Preview pane for example), for each object field name(s) in your script.

If that is what you've been struggling with all along, just don't append the # symbol or anything else in your scripts except for the plain original object field name exactly as it is spelled in the object field (not as it is shown in the Right Hand Preview Pane when you work with the Prepare Form tool).

Just use the original field name in the scripts

However, in your original inquiry you did said :

"When I "duplicate across page" the new lable adds a "#" to the new field name AND NOW it can not be calculated. "

You did not indicated :

"I need to caluculate form fields independent of each page.  "

If that is what you were asking all along, then you need to use the "Create Multiple Copies..." action, which will rename the copied  field objects.

In fact, it appends a period at the end of the field object parent name, followed by a number (in sequence for each copy), not a hash pound symbol "#".

As @Bernd Alheit mentioned, however, if you are duplicating  accross pages, this method will force you to modify the name of all the copied field objects if you want to make them work independently from all other copies accross different pages.

That said, you must select the appropriate names for any type of calculation employed, wether it be via JavaScript script, Simplified Field Notation (SNF), or with the built-in Calculate method: "Value is the".

[atkin31]

So basiclly, there is no way to do this other than manually? 

[Bernd Alheit]

New names for the fields are possible with a script or plugin 

[ls_rbls]

Unfortunately, no.

There is no other way but manually.

And I forgot to also clarify, that when you use  "Create Multiple Copies..." it will also rename the original field(s) that you are copying from. It is very different from duplicating fields accross pages.

 What the "Create Multiple Copies..." action does is to arrange a hierarchy structure of "Parent-Child" field name convention.

It would look something like "Text1.0".

"Text1" before the period is the Parent name for all the copies of that object.

Text1.0, Text1.1, Text1.3 are the childrens of Text1.

Let's say that you want to create a copy of an existing  row of text fields that are named Text1, Text2, Text3 respectively.

After the multiple copies are created you'll notice that those 3 field objects are named in sequential order: Text1.0, Text2.0, Text3.0 and depending on how you wanted them they could represent  a new row or a new column.

In which case, the suffix ".0" indicates that those fields in that row are the first item.

Text1.1, Text2.1, and Text3.1 in the new row represent the second children group of the same parent object  that was copied.

NOTE:

"0" is always used by the JavaScript core interpreter to denote the the first item for any PDF element or objects, such as groups of widgets ( like buttons, radio buttons, checkboxes), in addition to dropdown menus,  listboxes, date field objects, printers, a document's pages, etc).

In which case a small script, as suggestet by  @Bernd Alheit will suffice or even using  a paid-for tool that can automate this task for you.

So I feel your struggle  myself at work with my own PDFs.

Your observation could be a great feature to add in Acrobat Pro.

Meanwhile, the best way to work around this manually is to design a better workflow before you duplicate any fields.

For instance, if I have a big group of fields consistingof 30 rows down and 8 columns width, I would select and copy only the first row of of fields.

And use the Duplicate Accross Pages action.

Then to make sure that you have a consistent clean workflow accross your entire document and to make those copied fields work independently from the other fields in other pages, just pre-fix them like this before you copy them:

Page1.Text1

Page1.Text2

Page1.Text3

You can apply the  "Create Multiple Copies..." action and they will be renamed to:

Page1.Text1.0

Page1.Text2.0

Page1.Text3.0

Now you can ducplicate this group accross pages for Page 3 for example.

Pre-fix them like: 

Page3.Text1

Page3.Text2

Page3.Text3

And when you apply  "Create Multiple Copies..." they will be renamed to:

Page3.Text1.0

Page3.Text2.0

Page3.Text3.0

Page3.Text1.1

Page3.Text2.1

Page3.Text3.1

The underestimated value of the parent-child hierachy when naming field objects is that this convention works great with JavaScript scripting.

If you need to perform a calculation that involves a large group of fields, you can take just  the parent field name in your calculating expression and it will automatically parse the array of all the field objects in that document that with the same parent name.

So if you use a calculation  in a script and you only indicate  "Page1." as the parent field name in that script, then only all fields with the parent name of "Page1." will be affected (not the ones on Page 3, for example)

And if you want to be more specific with other types of calculations on a specific group of fields that are grouped in the same page of a document, then  you may tweak that script to use "Page3.Text1." as the parent name object which will affect all of its children only.

[try67]

> So basiclly, there is no way to do this other than manually?

There are, but they involve quite complex scripting solutions.

[JR Boulay]

In fact, the solution is so simple that few people think about it.

One just have to copy-paste all fields in another document to rename them, and then to copy-paste back in the original document.

Animated tutorial: