Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Only first row of dynamic table saves to pdf

Avatar

Level 4

Please help me with this.  I have a dynamic table in an xdp that can grow by adding rows (called details).  This appears to work in the browser, when I edit.  However, when I save to pdf, only the top row saves.  Any idea why the entire table is not saving to the PDF?  Thanks in advance.

1 Accepted Solution

Avatar

Correct answer by
Level 4

I compared the xdp's markup files for the form that worked and the one that didn't.  I found that there was a line named templateDesigner expand {b.t.w. paste doesn't seem to work in this window right here, which is irritating}.  Anyway, in the form that did not work, this was 0 and in the one that did work it was 1, so I assume that this is why.

I wanted to correlate this with a checkbox in the hierarchy in the Adobe Livecycle Designer GUI, but I could not yet, and right now I have other projects to work on.  However, hopefully this will help others with this problem.

If anyone knows where the checkbox for this is in the hierarchy in Adboe Livecycle Desinger, please post here.

The comparison tool I used was SVN diff which will open WinMerge if installed on your machine.  The two working together form a *very powerful* comparison tool.

Of course, editing the xdp can be very risky, so be careful if you go this route.

Thanks!

View solution in original post

9 Replies

Avatar

Level 10

Under File>Form Properties>Defaults make sure that "Preserve scripting changes to form when" is set to "Automatically."

Avatar

Level 4

On my particular instance of Adobe LiveCycle Designer, this is under Form Properties -> Run-time -> Scripting Box:  "Preserve Scripting changes to form when saved".  For me, I already had this option ("Automatically) selected, I tried also checking a check box at top saying "Allow Automatic Saving of Document Changes to Temporary FIle); but this didn't work either.

Still, I really appreciate you taking the time to reply to my question.


Do you or anyone else have any ideas?

I don't know whether the problem is with the form itself, any subforms involved, the table, or the rows.

I have a similar form that is working, however, comparing two xdp documents is extremely difficult.

Avatar

Level 4

Yes, I experienced this problem just today. I have a dynamic form created in Live Cycle Designer that has one table with a control that permits the user to expand rows in the table through the Instance Manager. I am assuming that is where my problem is. The table adds/deletes rows effectively, but when I distribute the form, the corresponding response file is created with only fields for one row in this table.

When you begin collecting responses, if a user submits a completed form with more than one row in the dynamic table, an error message will be generated that the form data doesn't match the response file structure. If you ignore the error and save the reponse, all rows beyond Row 1 will not be saved.

I have not solved the design/coding issue yet, but I did develop a workaround. I opened the form_distributed.pdf and filled-out a bogus response, filling in as many rows in the dynamic table as I thought the universe of users would create. I then submitted the form. I then opened the submitted response and was prompted by Adobe to save the pdf to the response file. I checked save it to another file, then merely replaced the existing form_responses.pdf that only had 1 set of fields for Row 1. With the save, it now has fields to accept up to the number of rows I added in the bogus submission. I export to a cvs file then edit the field names to avoid duplicate field name issues in subsequent data analysis.

There clearly must be a better and more eloquent solution.

Avatar

Level 10

Hi,

I might be a binding expression gone wrong, have you and binding expressions that have a number in them like detail[0], it should be something like detail[*].

We would otherwise need to have a look at the form,  are you able to share it and add a link to this thread.

Bruce

Avatar

Level 4

Hi Bruce:

I don't think I can post my form but I do have a form with a working table where everyting saves correctly.

I pasted that table into my other form, and it too didn't work.


Therefore, I am guessing that my problem is a *form* property and not a table property.

I checked all the usages of detail[] in my form, and nothing seemed wrong to me...

Any thoughts, anyone?

Thanks again!

Avatar

Level 4

Does anyone know a good way to compare two xdp files for differences?  WinMerge seems to not be able to handle it...

Avatar

Correct answer by
Level 4

I compared the xdp's markup files for the form that worked and the one that didn't.  I found that there was a line named templateDesigner expand {b.t.w. paste doesn't seem to work in this window right here, which is irritating}.  Anyway, in the form that did not work, this was 0 and in the one that did work it was 1, so I assume that this is why.

I wanted to correlate this with a checkbox in the hierarchy in the Adobe Livecycle Designer GUI, but I could not yet, and right now I have other projects to work on.  However, hopefully this will help others with this problem.

If anyone knows where the checkbox for this is in the hierarchy in Adboe Livecycle Desinger, please post here.

The comparison tool I used was SVN diff which will open WinMerge if installed on your machine.  The two working together form a *very powerful* comparison tool.

Of course, editing the xdp can be very risky, so be careful if you go this route.

Thanks!

Avatar

Level 4

Readers of this thread may also be interested in my thread here on an expanding table crowding the elements below it:

http://forums.adobe.com/message/5388909