[mkraft]

I frequently have a terrible time with Word tables when I need to 'insert'
columns, especially (but not only) if one or more header rows contains a
merged cell that spans two or more columns.

The kinds of strange results I generally get leave the impression that Word
actually treats header rows as separate tables that are joined to the actual
table's 'data rows,' because the behavior of the header row columns after
attempting such column insertions is often distinct from that of the columns
in the rest of the table.

What I find over and over is that even if the new column inserts more or
less correctly, the header row(s) don't reformat in a way that recognizes it.
In almost all cases, the cell border lines in those header rows end up all
over the place and for some reason are often very difficult to realign with
the non-header row border lines for those columns.

I usually end up 'undoing' the column insertion and instead splitting the
adjacent column and then converting one half of that split column into the
new column. As much work as that can be, it seems to end up better than
trying to use the 'insert column' feature.

Is there any other (better) solution to this?

Thanks.

[macropod[_2_]]

Hi mkraft,

You might get better results if you split the table just below the header row before inserting the new column(s) and inserting them
into both of the tables thus created before rejoining them.

--
Cheers
macropod
[MVP - Microsoft Word]


"mkraft" wrote in message ...
I frequently have a terrible time with Word tables when I need to 'insert'
columns, especially (but not only) if one or more header rows contains a
merged cell that spans two or more columns.

The kinds of strange results I generally get leave the impression that Word
actually treats header rows as separate tables that are joined to the actual
table's 'data rows,' because the behavior of the header row columns after
attempting such column insertions is often distinct from that of the columns
in the rest of the table.

What I find over and over is that even if the new column inserts more or
less correctly, the header row(s) don't reformat in a way that recognizes it.
In almost all cases, the cell border lines in those header rows end up all
over the place and for some reason are often very difficult to realign with
the non-header row border lines for those columns.

I usually end up 'undoing' the column insertion and instead splitting the
adjacent column and then converting one half of that split column into the
new column. As much work as that can be, it seems to end up better than
trying to use the 'insert column' feature.

Is there any other (better) solution to this?

Thanks.

[mkraft]

"macropod" wrote:

You might get better results if you split the table just below the header row before inserting the new column(s) and inserting them
into both of the tables thus created before rejoining them.

I did not find that this strategy worked at all. Splitting the data rows
from the header rows (thus creating two separate tables) allows column
insertions in the table to format acceptably (even those need some
'cleanup'), but in the table containing the header rows (i.e., even after
being separated from the table) everything ends up a mess (which has
consistently been my experience with Word tables). Not just a mess -- an
impossible mess. Trying to fix it takes longer than just recreating the
header rows. That shouldn't be necessary, however, in a supposedly advanced
word processing program.

It's incredible that after all these years Microsoft still can't get this
(tables) right.