Adobe LiveCycle (Archived)

Report · 2/2/15

I have a form with a repeatable subform. Let's call the subform <Five> since it has a maximum occurrence count of five. Within <Five> is a table with a repeatable body row that we'll call <Body>.

<Five> uses a script in the calculate event that refers out to a static set of check boxes to determine how many instances of itself the form should contain. <Body> contains no scripting except the LiveCycle-created action that allows the form user to delete the instance of <Body> the button is contained within.

<Five> works great at run time and initializes just fine. <Body> removes all but one row when the form is opened.

Any ideas about how I'm losing data and how to correct it?

ScatterToo · 2/4/15

Check the Object-Binding tab for the minimum/maximum repeat settings. The min may be set to just one?

Magus069 · 2/4/15

Hi there

I've ran into this problem too many times, and there could be more than one reason to explain its behaviour...

But here's the most common reasons..

1. Some of your repeatable objects have the same name and somehow acrobat is misreading the file and changes the instance of an object equal to the other object which has that many instances..

E.g.: You have 2 tables in your form respectively named Table1 and Table2 in 2 different subforms.. But both have their row names Row1.. this could create an error in your form

2.If you are not quite sure what to check at first, this above reason might not do the trick.. you should make a copy of your form on the side and start testing it out. Delete repeatable objects from your hierarchy and retry your form.. until it does not change the instances of your subform/row... Once you have found which object is making this, try anything as changing its name at first, or deleting the object and recreate it

Hope this help!

Report · 2/4/15

The binding, in the case of the repeating subform and table is set to use name. This would create a path of Five[0].Table[0].Body[0] for the first instance and Five[1].Table[0].Body[0] for the tables and rows, I think. The XML should recognize the various instances without issue.

This did, however, remind me that I have the form mapped to a schema and that the schema did not include an analog to the row values. Adding elements to the schema with maxOccurs="unbounded" and mapping those to the row fields seems to have fixed the data loss problem.

Now I'm trying to figure out why the export drops one field value on the third iteration (index value 2) of the row.

Thanks for the input.

Report · 2/4/15

I thought about the naming concern, but the index values of the subform within which the table is present should be sufficient to avoid XML confusion, i.e. Five[0].Table.Row[0] is not the same as Five[1].Table.Row[0], despite both rows being being Table.Row[0]. I'm reasonably sure this would be a larger issue if I were flattening the XML on output and not exporting mapped to a schema that provides context for field values and location within the form.

I did make a copy of the form (good advice and good practice) and work with that. Also made a copy of the schema and modified that so I could revert if anything broke.

Report · 2/4/15

More context should be given. Too easy to forget the details when frustrated with things not working.

The form in question is mapped to a schema and the schema had no elements analogous to the rows that were disappearing. Adding unbounded elements to the schema and properly connecting those to the form fixed the issue of data loss within the PDF. This gave rise to a new issue, viz. the schema-mapped XML that is exported drops, as far as I have tested, the third (index 2) iteration of one field value.

For example, the exported XML contains six fields that iterate, that we will call Type1, Source1, Description1, Type2, Source2, Description2. The XML will look something like <Type1>Text</Type1><Source1>Inventory</Source1><Description1>Qty. X of Part Y</Description1> etc., but the third iteration is <Type1/><Source1>Inventory</Source1><Description1>Qty. A of Part F</Description1>. The underlined element is the one that is consistently dropped on the third go 'round. I'm going to continue testing and see if there is more to it — i.e. Does it drop every third iteration or only the first? — or if it is just some glitchy thing going on.

Adobe LiveCycle (Archived)

Why am I losing repeatable rows in a table within a repeatable subform?

Learn

Documentation

Community

Support

Resources

Adobe account

Adobe