Probably because of header and/or footer rows.
table.rows.length should be the same as table.headerRowCount + table.bodyRowCount + table.footerRowCount
Peter, by necessity (.. well, the DOM model) bodyRowsCount must be <= rows.length. OP reports the opposite.
BurtonDev: write a script to put row numbers into each cell of your table, then show a screenshot. InDesign's table model is straightforward and all merged cells still count as 'real' cells. You can even accidentally get or set text into them... So that cannot be the cause.
> OP reports the opposite.
Hadn't even spotted that. Maybe he mixed things. How can a table have fewer rows than body rows. Can't imagine that you could achieve that even with some diabolical cell merging
Hi BurtonDev ,
can you upload a sample of the document with the table to a service like Dropbox and post the link here?
I'd like to see a table with a row length that is less than bodyRowCount.
At what point in time do you measure rows.length?
Did you remove rows before? Or did you merge cells before?
I did what you suggested - wrote a script to insert the row index into each cell of the table, and got some very, very odd results.
This was a great suggestion. I'm seeing a pattern, but I'm still not totally sure what's causing rows.length to be < .bodyRowCount.
Here's a screenshot of rows indexed 0-4 in one of the tables:
That looks pretty crazy to me. As you can see, in the fifth column from the right, row index 1 is empty and row index 2 contains both 1 and 2.
The rest of the columns to the right have the same thing going on every other column with rows indexed 0 and 1. The cells that are blank with 0 and 1 in the cell beneath are cells that contained form fields. To create these form fields, I first selected the cell, applied "Convert Cell to Graphic Cell", then selected the graphic cell and picked "Text Field" from the "Buttons and Forms" Type droplist. Of course, since the script replaced the contents with the row index, the text fields are no longer in the cells.
This seems to explain the aforementioned columns, but it doesn't explain the column where the 1 and 2 are in the same cell. I didn't use any form fields or graphic cells in this column. So it still seems to me a bit of a mystery...
What's even weirder is that the displaced text still behaves as if it is in the correct cell, even though it doesn't appear to be.
For example, I can highlight and select the emptiness in the cell without selecting the entire cell and apply a change, such as changing the text color, and the change will be applied to the text in the cell below:
In the screenshot above you can see the blank selection and the 0, changed to cyan. Any change I make to the selection or its cell will change the 0 in the cell below, even alignment. This is how the cell looks bottom aligned:
And this is the same cell top aligned:
Even when top aligned, the 0 is still half inside the cell below and is nowhere near the top of the selected cell (and yes, there is 0 inset on all four sides of the cells).
FYI the entire table is composed of body rows. There are no header or footer rows, though I don't think that it matters in this case.
Anyone have any insights?
I forgot to mention that I had resized the columns for the screenshots so that you can read the numbers. In the original layout, all the columns with 0 in the top row that appear as expected (with the exception of the ones with the merged cell) were set to a width of 4 pt. IDK if the narrow column width might be a factor...
just visualize what exactly row with index 0, 1, 2, 3 etc. means:
// Select the text frame holding the table: var indexOfRow = 0; var selectedTextFrame = app.selection; var table = selectedTextFrame.parentStory.tables; app.documents.select( table.rows[ indexOfRow ] );
Then check for other values of index.
If you see something surprising with a distinct index number do a screenshot and post it here.
About formatting text with form fields that are located in graphic cells:
I experienced the weirdest things with items in graphic cells that are not images or graphics.
That's weird. When I do a table as in your screenshot, rows.length is the same as bodyRoWCount.
Do another experiment: instead of the row indexes, in each cell write the its name (...contents = cells[i].name). That prints in each cell a string of two numbers separated by a colon. The first number is the colum index, the second, the row index. Row and column spanning, especially when combined, can make tables difficult to process.
1 person found this helpful
I don't think it's crazy.
Maybe the vertical shift of some of the numbers is done by formatting with baseline shift.
Is the parent of that "rows" expression eventually referring to a column rather than to the table? In that case you could see to the result after merge of cells.
Besides, even if it started off as reference to the table, it might have become corrupted in some way by previous changes, the same way that happens to text references (where we usually iterate find-change results from back to front ...)
It would be interesting to see the toSpecifier() of that assumed table reference, also whether it still yields wrong results if you rebuild the reference to the table.
To answer all your questions/comments:
Peter Kahrel: I also got bodyRowCount == rows.length when I used a fresh table in a new document, but I was getting bodyRowCount > rows.length in the problem tables. I tried outputting the cell name into the cells as you suggested. The result was as expected, with the exception of the "weird" cells... which Uwe rightly surmised was due to baseline shift.
Laubender: Somehow I must have clicked on a character style with a baseline shift while the cells in question were selected. I can't think of how else the baseline shift was applied because it was not intentionally applied. But you were correct. Once the baseline shift was eliminated, the cells appeared as normal.
Regarding the inspection of the row index - the script I wrote iterated through all the cells and wrote rows[x].index.toString() to cells[y].contents. So I was looking at the actual index for the row, not the value of the iterator.
Bottom line: neither row index or cell name revealed anything amiss.
Dirk Becker: By the time I came across your comment, I had recreated the tables from masters and deleted the offending pages, so I was not able to test app.selection.parentStory.tables.rows.parent.toSpecifier() on the problem tables .
I have tried without success to recreate the error. I noticed that it seemed to happen while debugging "Object is invalid" errors. I recreated one of these errors in my code but it did not cause the bodyRowCount > rows.length error again.
I guess this will remain a mystery unless I or someone else can recreate the error. Thanks for all your help.
https://forums.adobe.com/people/Dirk+Becker : By the time I came across your comment, I had recreated the tables from masters and deleted the offending pages, so I was not able to test app.selection.parentStory.tables.rows.parent.toSpecifier() on the problem tables .
Such specification — app.selection.parentStory.tables.etc.etc — is obviously of the kind that Dirk was suspecting potentially corrupted, or at least very unstable, in terms of object reference. There are good reasons to think that the actual target of your bodyRowCount command was not or no longer, at the time you sent it, the assumed object. And the fact you met "Object is invalid" errors while debugging your script tends to reinforce this view. Having some piece of code to study would have helped a lot.