Word VBA uniform table property not working

[smallken]

I am trying to use the Table.Uniform property to determine if a table has merged or split cells.

The problem is that with some tables the Uniform property gives a "False" value even though the table is uniform. With such tables, statements such as Selection.Tables(1).Rows.Cells.Count work whereas if the table were in fact not uniform a 5991 error would occur.

The method that I use to determine if a table is truly uniform is to get the row and column number of every cell in the table to determine the number of cells in every row with:
ReDim cellsInRow(aTable.Rows.Count)
For Each aCell In aTable.Range.Cells
cellsInRow(aCell.RowIndex) = aCell.ColumnIndex
Next aCell

However this is time consuming for large tables.

Does anyone know how to overcome the bug with the Table.Uniform property or a better way than mine to identify uniform tables?

PS I have tried using error trapping but it still time consuming.

 

[TonyJollans]

As far as I know the Uniform property is correct. It is your interpretation of what it means that is incorrect.

If a table has, say, two cells different sizes from the rest, or if it has merged horizontal cells, it is not uniform, but it will still give correct results for the .Rows.Cells.Count property.

Worse, in a sense, is that your code will not tell you anything about the uniformity of a table. It will, for example, count vertically merged cells once for each row they span.

What are you trying to achieve when you have determined whether your table is uniform?

Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website

 

[smallken]

I stand by my statement that the Uniform property does not always work. It seems to go astray if the document contains several tables, some uniform and some with merged cells. At first use on a uniform table it gives a True value but if other tables are processed then on returning to the same uniform table its value for that table is changed to False.

I am writing routines to clean up tables by column, aligning text, removing unnecessary tab settings, removing leading and trailing tab and space characters etc. It also overcomes a bug in setting tabs in tables via the ruler drag and drop that has been perpetuated with different versions of Word.

If a table is uniform then I can use the code:
For ir = 1 to atable.Rows.Count
Set acell = atable.Rows(ir).Cells(col)

If the table is non-uniform then the above code raises an error and I have to use the code:
For Each acell In atable.Range.Cells
If acell.ColumnIndex = col then ‘ have found a cell in column col

The second method is much slower which is significant because VBA is abysmally slow in Office 2007 and only marginally better in Office 2010 compared with Office 2003. I am talking of up to 20 times slower.

I need to apply the code on tables with up to 400 rows.

 

[SkipVought]

I set up a simple table in MS Word
[tt]
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
[/tt]
Uniform is TRUE

Split a cell
[tt]
+--------+--------+-----------+
| | | |
+----+---+--------+-----------+
| | | | |
+----+---+--------+-----------+
| | | |
+--------+--------+-----------+
[/tt]
Uniform is FALSE

Merged two cells
Split a cell
[tt]
+--------+--------+-----------+
| | | |
+----+---+--------+-----------+
| | | |
+----+---+--------+-----------+
| | | |
+--------+--------+-----------+
[/tt]
Uniform is FALSE

Aligned ROW 2 so that all columns for all rows are of equal size
[tt]
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
| | | |
+--------+--------+-----------+
[/tt]
Uniform is TRUE

Does this demonstrate that unless a table's row & column dimensions are equal across the column & row, that it is not just the numbere or rows or columns per column or row.



Skip,

_{Just traded in my old subtlety...
for a NUANCE!}

 

[smallken]

The Word 2010 Developer Reference defines the Table.Uniform Property as:
"True if all the rows in a table have the same number of columns. Read-only Boolean"
Which means that ShipVought’s third table should return True.

Try this:
Create a table using Insert Table and check its Uniform property. It should be True. As created, the vertical alignment in all of the cells is Top. Now change the vertical alignment in one of the cells to Center or Bottom. You will find that the Uniform property for the table is now False.

This also happens if you change the vertical alignment of all of the cells in the table. If you change all the cell alignments back to Top then the Uniform property becomes True again.

Despite the Uniform property of the table being False, statements that would raise errors for non-uniform tables (I mean tables that have combined cells) work without raising errors.

 

[TonyJollans]

The [blue]Uniform[/blue] property has a meaning (essentially that all cell properties are 'same as table'), but not the meaning you need. Perhaps there are bugs in it, I don't know; all I can say is that I haven't come across them. Microsoft Help is rubbish, and getting more so: please tell me something I don't know! Ok, you have - some VBA in Word 2007 is slow; I didn't know that included working with Tables, but I'm happy to believe you.

Now, you have a requirement. You don't state it in detail, so it's hard to help much, but, perhaps a couple of pointers ..

.. only you know what your tables are like, but you need to be careful using row and/or column index numbers if you have merged cells or you might find you are not referencing the cell you thought you were. If you know (or can trap the error), for example, that you don't have vertically merged cells you would then know that you could reference rows safely, which might get you some way to keeping your code simple.

.. referencing rows (or, more generally, items in any collection) by number gets progressively slower the further into the table you go, so, this sort of code ..

For ir = 1 to atable.Rows.Count
   Set acell = atable.Rows(ir).Cells(col)

would be better and faster like this, especially on large tables ..

For each TRow in atable.Rows
   Set acell = TRow.Cells(col)

Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website

 

[smallken]

Thanks for your comments but unfortunately

For each TRow in atable.Rows
Set acell = TRow.Cells(col)

raises an error when there are vertically combined cells.

Since the Uniform property has bugs I guess that I will have to continue using the slow way that at least works for all table configurations.

For Each acell In atable.Range.Cells
If acell.ColumnIndex = col then
' cell in column col

The tables to be cleaned up are in documents prepared by others so I have no control over their content. You would be amazed at the mess some people make of tables.

I haven't yet tackled tables within tables.

 

[TonyJollans]

My apologies. Your options are limited when you know nothing of the table structure.

You are right that performance working with large tables is abysmal - I just did some experiments and all I can say is that I found 2007 better than 2003 but still awful - even with uniform tables. It might be worth trying to iterate over paragraphs rather than cells - you'll need to experiment - but nothing else springs to mind; I fear you are stuck with having a coffee break when you run the real thing :-(


Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website