Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Saving .PDF with Repeatable Subforms Adds a New Instance.

Avatar

Level 4

Hey everyone,

I've been working with LiveCycle Desinger dynamic forms for a few years now, and this is the first time that i'm seeing this sort of behaviour.

I have a very large form open in LiveCycle Designer. It has or 50 different repeatable subform sections. I save it from Designer, then open it in Adobe Acrobat X Pro. From Acrobat Pro, each time I resave it then reopen it, a new instance is added to each repeatable subform.

If I fill it in, save it, then reopen it, it has all of my info, plus an additional blank subfrom below each section.

I have no formcalc in the presave, nor do I have any global fields in my form... Also, each repeatable subform is uniquely named. I'm at a loss.

I have a sample of this pdf here. If you have another file hosting site that you would prefer, just let me know.

I would really appreciate any help that anyone could offer. I have no idea what's causing this.

- Scott

1 Accepted Solution

Avatar

Correct answer by
Level 4

Hello again everyone,

I've found the answer to my own problem. I had a heck of a time Googling the issue, so I'm going to put some of the phrases I tried at the bottom, in case some like-minded individual has a similar problem.

The main issue was with the databinding. I had left the databinding for everything as the default 'use name (...)'. I was under the impression that so long as no sibling elements were named the same thing, there wouldn't be a conflict. I was wrong.

In my form, I used static subforms to organize the layout of fields within a dynamic repeatable subform. The static subform was called 'sf_positioning'. It just so happened that this field had an uncle named the same thing. This was close enough to cause a conflict, making the repeatable subform register an additional instance each time the data was saved. This can be fixed in one of two way... 1) set one of the offending subforms to use 'no data binding' (only use this if the content of the subform isn't to be exported or merged) or 2) give the subforms unique names.

I need to look into whether everything needs to be uniquely named... Like I said, it made more sense to me that the only restriction should have been on the sibling elements, but from now on I'm going to make sure that there are at least three degrees of separation between any like named controls/subforms.

Hope that helps someone else...

And the following were some of my attempts at googling the issue. Hopefully this will mkae the solution easier to find for others:

- Reader extending dynamic form breaks repeatable subforms.

- Saving adds a new instance to repeatable subform.

- Every time I save, I get more blank instances of a repeatable subform.

- Repeatable subforms not functioning as expected.

View solution in original post

4 Replies

Avatar

Correct answer by
Level 4

Hello again everyone,

I've found the answer to my own problem. I had a heck of a time Googling the issue, so I'm going to put some of the phrases I tried at the bottom, in case some like-minded individual has a similar problem.

The main issue was with the databinding. I had left the databinding for everything as the default 'use name (...)'. I was under the impression that so long as no sibling elements were named the same thing, there wouldn't be a conflict. I was wrong.

In my form, I used static subforms to organize the layout of fields within a dynamic repeatable subform. The static subform was called 'sf_positioning'. It just so happened that this field had an uncle named the same thing. This was close enough to cause a conflict, making the repeatable subform register an additional instance each time the data was saved. This can be fixed in one of two way... 1) set one of the offending subforms to use 'no data binding' (only use this if the content of the subform isn't to be exported or merged) or 2) give the subforms unique names.

I need to look into whether everything needs to be uniquely named... Like I said, it made more sense to me that the only restriction should have been on the sibling elements, but from now on I'm going to make sure that there are at least three degrees of separation between any like named controls/subforms.

Hope that helps someone else...

And the following were some of my attempts at googling the issue. Hopefully this will mkae the solution easier to find for others:

- Reader extending dynamic form breaks repeatable subforms.

- Saving adds a new instance to repeatable subform.

- Every time I save, I get more blank instances of a repeatable subform.

- Repeatable subforms not functioning as expected.

Avatar

Level 4

Note: I removed the my sample pdf, so the link is now broken.

Avatar

Level 1

Thanks for posting this.  I was going nuts trying to solve the same problem.

Avatar

Level 6

I've spent HOURS+++ trying to find a solution only to discover that the field names within a repeating subform must be unique. Case in point, when I had a subform containing 3 fields: TextField1[0], TextField1[1], TextField1[2], I ran into an issue where a new instance of the subform was created each time the form was opened and saved. VERY AGGRAVATING! However, by changing the names of each field within the subform, the issue was resolved!

NOTE: Considering, I needed to use that same subform in my form again, I made sure to give the subform #2 a unique name, as well as the fields within the subform. Doing so allowed me to keep the data binding of the subform set at 'Use name (...)'

I hope this info helps someone else in the near future.