Bug: Table Columns Rendered Incorrectly with New Column Width
Description
When changing a table’s column widths via the table object’s “columnWidths” attribute, the table’s columns will not be rendered correctly.
For example, consider the following table:
Clicking on the “Expand Columns” button sets the width of the first column to 2 inches and the width of the second column to 3 inches with the following script:
Table1.columnWidths = "2in 3in";In Acrobat 8.0 or earlier, this is the result:
The problem is that the table’s layout hasn’t been properly updated after the changes to its column width attribute.
Workaround
Fortunately, there’s a simple workaround to this problem which consists in forcing an update to the layout after setting the column widths of a table:
Table1.columnWidths = "2in 3in";
xfa.layout.relayout();Note that a lot of these table rendering issues have now been addressed in Acrobat/Reader 8.1.
When using the above workaround or Acrobat/Reader 8.1, this is the result you get:
Fix
Please refer to the Bug List for updated information on the version(s) affected by this bug as well as if and when it was/will be fixed.
Posted by Stefan Cameron on June 13th, 2007
Filed under Acrobat,Bugs
Both comments and pings are currently closed.
Hi Stefan,
(It looks like the one of the “less than” symbols in a loop statement was causing problems in my last post. Here’s another attempt.)
I’ve been running into some problems with dynamic tables and I was wondering if you had any ideas about the cause. So first off, here’s the code I’m using to create a 4×3 table. The code is called on initialize of my Table1.
app.alert(“here\’s an alert”);
var myColumns = “Col1Name,Col2Name”;
var arrMyColumns = myColumns.split(“,”);
//add 2 instances of Row1
Table1._Row1.addInstance(0);
Table1._Row1.addInstance(0);
//populate the static header row
Table1.HeaderRow.ColSF.ColNameTxt.rawValue = “Col0Name”;
//populate each cell in the first column
for (var j = 0; j < Table1._Row1.count; j++)
{
Table1.resolveNode(“Row1[” + j + “]”).ColSF.ColNameTxt.rawValue = “text”;
}
//create and populate the rest of the table
for (var i = 0; i < arrMyColumns.length; i++)
{
//create a new column
var oNewCol = Table1.HeaderRow._ColSF.addInstance(0);
oNewCol.ColNameTxt.rawValue = arrMyColumns[i];
for (var j = 0; j < Table1._Row1.count; j++)
{
//get Row1[0], then Row1[1], …, Row1[j-1]
var oRowInstance = Table1.resolveNode(“Row1[” + j + “]”);
//add a new column to the instance of the row for each column added to the header row
var nCol = oRowInstance._ColSF.addInstance(0);
nCol.ColNameTxt.rawValue = “text”;
}
}
xfa.layout.relayout();
The table name is “Table1”. The table has one header row called “HeaderRow” and one body row called “Row1”. Each row (the header row and body row) contain a text field called “ColNameTxt”. Each ColNameTxt field is wrapped in a subform called “ColSF”. All rows and subforms are set to flowed and “Repeat Row for Each Data Item”.
Problem 1:
If I use the code I posted above, then everything loads fine. The problem is, there is an alert each time I open the pdf. If I comment out the line of code which prompts the alert, then the table is drawn really weird.
Problem 2:
Assuming I leave the alert turned on in the beginning, I can save the file from acrobat (File…Save As), but when I go to open the newly created file, it’s drawn all funky again (the alert still pops up though).
If you want to take a look at any of the files I’ve been working with, just let me know and I’ll send you a few of them.
Thanks again for all of your help!
Brent,
I think the problem is that the call to “xfa.layout.relayout()” is occurring too soon as the form is loading, hence why the table appears to be messed-up. When you put the alert message in the code, it must cause a delay in the time at which the “xfa.layout.relayout()” call occurs — a delay just long enough for things to be in place such that the re-layout does what it’s supposed to do.
If I’m correct, then you could try moving your script to the table’s “Layout:Ready” event, which occurs once form has been loaded/initialized and all changes, if any, have been rendered. The only catch is that this event fires constantly (every time something changes) so you’ll have to “protect” your script with an IF statement to prevent it from executing all the time. You could simply check to see if the instance count of the Row1 Instance Manager is greater than zero. If it is, don’t execute the script:
As a side note: I tried to reproduce the weirdness you were describing in the table's rendering using Acrobat 8.1 and wasn't able to reproduce it. I got a nice table right from the start, without even the need for "xfa.layout.relayout", which means that the new dynamic form renderer in Acrobat/Reader 8.1 has fixed a few of these table layout bugs.
I created a form in LiveCycle and I followed the instruction to use a button to dynamically add lines to a table. When opened in Reader I can generate the lines and add information and print it, but I save the form and open it later the rows are gone and only the original remains. It does remember the first rows information but loses everything else.
Any one have any thoughts?
I do did ‘enable usage rights in acrobat reader’ with Acrobat Pro.
It appears to have something to do with XML. I have it linked to an XML file and Acrobat doesn’t like saving that. If I just create an unbound table it will save the rows just fine.
Jim Terryberry,
I wasn’t able to reproduce the behaviour you’re describing with saving and re-opening table row data in Reader on a Reader-Enabled (via Acrobat Pro’s “Enable Usage Rights in Reader” feature) when this form has a data connection to a schema (assuming that’s what you meant by “I have it linked to an XML file” in your second comment, #4 above).
It’s quite possible that’s because I’m testing this using Acrobat Pro 8.1 and Reader 8.1. I’m unable to try it with previous versions of Acrobat and Reader. Acrobat/Reader 8.1 introduce many significant changes with respect to dynamic XFA forms. It’s quite possible the issue you’re describing was addressed in those changes.
Hi Stefan,
help please.
my form contains a dynamic table spanning across multiple pages. based on a radio button i need to make the table read only so that it cannot be modified. i made the table1.row1.rawValue.access=”readOnly”;
but it makes only the first row only as readOnly and the rest of the rows can be modified as usual. i wish to make all of them readOnly.any help much appreciated. hope i m clear on my question
thanks
sri,
Given you’re setting the “access” property on a subform (table rows are subforms), I’m going to assume you’re using Designer 8.2 and Acrobat 9 since the XFA Subform element doesn’t get an “access” property until XFA 2.8 which was released along with these applications.
To set all the rows in the table as read-only, just set the table’s “access” property rather than the row’s:
Stefan,
I am using Adobe Designer 7.0 and Acrobat Professional 7.0. My problem is, Once I select a radio button and want to deselect that. I wrote the code to make it null. But the black dot on the radio button is still displayed. I believe this is a bug in the Acrobat. For this I tried xfa.layour.relayout(). It worked fine. But in one of my form, I have 3 pages and lot of fields. So When I used this relayout method, it is effecting performance of my form. So I tried to execute the layout ready event of the Radio button alone using following codes. But it is not working. Can you please tell me if any workaround is there for this. Thanks in Advance…
Following are the scripts we tried.
Radio Button Group Name : YesNo
YesNo.execEvent(“layout:ready”);
YesNo.execEvent(“ready:layout”);
Pavan,
Thanks for pointing this out: You did, in fact, find a bug and it still exists in Acrobat Pro 9! I’ll be adding an entry in the Bug List shortly. In the mean time, you can reset the selection by using the xfa.host.resetData() method:
Update Oct 9, 2008: Posted new article on this bug.