Inspiring

Question

Why is rows.length < bodyRowCount?

Forum|Forum|7 years ago
August 29, 2018
3 replies
1665 views

I'm writing a script that has to remove rows at the end of a table. It is not working as expected.

While debugging, I noticed that rows.length (29) is less than bodyRowCount (32).

How is this possible? Doesn't rows.length contain the entire collection of all rows and therefore should be equal to or greater than bodyRowCount?

What could be causing the rows.length to contain less than all rows in the table? Could it be merged cells? Is there a way to identify all merged cells in the table? Or is it something else?

Any help or insights are greatly appreciated!

This topic has been closed for replies.

BurtonDevAuthor

Inspiring

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.index.toString() to cells.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[0].parentStory.tables[0].rows[0].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.

Marc Autret

Legend

Hi BurtonDev

(…)
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[0].parentStory.tables[0].rows[0].parent.toSpecifier() on the problem tables .

(…)

Such specification — app.selection[0].parentStory.tables[0].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.

@+

Marc

L

Laubender

Community Expert

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?

Regards,
Uwe

BurtonDevAuthor

Inspiring

Hi, Uwe / Laubender.

Unfortunately, I cannot share the document. However, I am going to try what [Jongware] suggests and post the screenshots in this thread. Stay tuned!

Peter Kahrel

Community Expert

Probably because of header and/or footer rows.

table.rows.length should be the same as table.headerRowCount + table.bodyRowCount + table.footerRowCount

Jongware

Community Expert

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.

L

Laubender

Community Expert

Hi, [Jongware].

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?

BurtonDev wrote
… 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.

I don't think it's crazy.

Maybe the vertical shift of some of the numbers is done by formatting with baseline shift.

Regards,
Uwe

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded