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 va...
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.Table.Row is not the same as
Five.Table.Row, despite both rows being being Table.Row. 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 an...
The binding, in the case of the repeating subform and table is set to
use name. This would create a path of Five.Table.Body for the
first instance and Five.Table.Body 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
I have a form with a repeatable subform. Let's call the subform
since it has a maximum occurrence count of five. Within is a
table with a repeatable body row that we'll call . 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.
contains no scripting except the LiveCycle-created action that
allows the form user to delete the instance of the button is
contained within. works great at run time and...
I have a form created in LiveCycle ES2. I have mapped some fields to a
schema that causes LC to generate XML that adheres to the import format
of one of my company's internal databases.There is one problem: the
system's import function looks for a DTD DOCTYPE declaration between the
XML declaration and root element. I've tried including the declaration
in the schema, but LC does not include it in the mapped values or the
export. I've spoken with the vendor about declaring the DTD as part of
If you choose to use fields the user has filled in, then yes. If you
choose to use fields that you have filled and set to hidden, then the
user will not see them, but the script WILL and it will use the data
contained in them to generate the email subject/body.
What I ran across in my searching (that worked) was to create hidden
fields that contained the data I wanted to use. I also used a "dummy"
submit button. The "real" submit button was created as a literal submit
button and the following code inserted into the click event of the
"dummy" button (which is a Regular button)This code was modified from
another's answer, but does the job. The field "SUBJECT" is set as
"Hidden" in the presence drop-down of the object tab. I suspect one
could add '&body='...