Word: Insert Row in table fails

[Julian Ladbury]

I have a VBA-based product which validates tables in various ways,
highlighting any errors it finds by updating the style of and adding a
Footnote to any text found to be in error.

While training a new user, I attempted to insert a row in a table (manually,
not using VBA), and encountered an error - no row was inserted, and some text
appeared where I would expect it to be.

I have investigated the problem and can recreate it. It appears to be caused
by a corrupt table. I have produced two files (one a doc, one a docx) which
can be used to reproduce the problem, pared down to the bare essentials
required to reproduce it.

I need to understand the precise nature of the table corruption so I can
understand whether it was originally introduced by my code, and whether I can
circumvent it.

The problem is described in more detail, together with screenprints, in some
files in my SkyDrive folder
http://cid-75e3e350f569b887.skydrive.live.com/browse.aspx/.Public/Bug30:

Bug30 description for MSDN.doc Describes the problem, has instructions as
to how to reproduce it using the next two files, and includes screenprints
Bug 30 Reproduce.doc Reproduces the problem in a .doc
Bug 30 Reproduce.docx Reproduces the problem in a .docx

 

[Colbert Zhou [MSFT]]

Hello Julian,

Thanks for contacting MSDN managed newsgroup support. I will be working on
the issue with you. This is best problem description I have ever seen! It
is very detailed and I can reproduce the issue in my Office 2007 machines.


I also do some tests in Office 2010 beta 2. The strange thing is that
sometimes I can see the issue, and sometimes it works as expected.

But, I think we cannot consider an issue resulted from document corruptions
as a bug, especially when the corruption parts can be recovered. In my
test, if I delete the second row, first cell's content. Then the issue
disappears. And this kind of issues do not happen to a new created table.
So the key point here is how we create this table.

We can know more about Word document corruptions from the following MVP
blog article,
http://word.mvps.org/faqs/apperrors/CorruptDoc.htm

We can know from there,
What cause the corruptions,
"If you use any of the following features, your documents are likely to
corrupt: Master Documents, Nested Tables, Versions, Fast Saves, Document
Map, and saving to a floppy."

Where stores the corruptions
"Corruptions are usually, but not always, stored in Section Breaks. The
final paragraph mark in a document contains a hidden Section Break, so in a
single-section document, corruptions tend to be stored in the final
paragraph mark.

Corruptions can also be stored in any paragraph mark in a document; or in
an end-of-cell or end-of-row marker within a table; or in a bookmark.
(Corrupt bookmarks are very rare in Word 97 and above, unless you have been
using EndNote).

If you find that certain commands such as Edit>Find don't work within a
certain table, that table is probably corrupt.

If you find text mysteriously disappearing and reappearing as you page down
past a particular paragraph, that paragraph's paragraph mark is likely to
be corrupt (see the section on fixing corrupt templates)."

How to recover the corruptions,
"Select File + Save As Web page, quit Word, reopen the htm file and save it
back in Word format ?that usually (but not always) gets rid of corruptions.
The HTML/XML format forces Word to completely re-create the internal
structure of the document, either fixing or discarding the corrupt bits
when it does. Best of all, in the case of Word 2000 and above, almost all
of the formatting and page layout is preserved.

Please note: to preserve your formatting, you must select the plain Save As
"Web Page" option, not the Save As Web Page (Filtered). If you use the
Filtered option, you remove from the document all the formatting that an
HTML browser cannot interpret: for example, page numbers and headers and
footers!

If that doesn't fix it, the fixes described below apply.

If using Word 97 or above:

If you have isolated the corruption to a particular table, either:
Paste the table into Excel; delete the Word table; paste the Excel table
back into Word, select the new table (Alt+Double-click), press
Ctrl+Spacebar to remove the manual formatting, and reformat the table, or:
Select Table + Convert Table to Text, select the text that results, and
select Table + Convert Text to Table. This has the advantage that you lose
much less formatting than using the Excel method, but the disadvantage that
if a corruption is stored in a paragraph mark within the table, it will
remain.
If the table contains horizontally merged cells, it's best to recreate a
few rows at a time ?for instance, if using method (b), then after
converting the table to text, select contiguous rows that have equal
numbers of columns, convert them to a table, and keep doing this until you
have converted all the text to individual tables (which will automatically
merge themselves into a single table).
......
"

I followed the suggestions above, first save the document as .mht web file
and then save it back to .doc .docx. Then I cannot see the issue any more.
Could you please give it a try and let me know if this resolves the concern
for you.

If there is any other further help I can provide, just let me know.


Have a nice day sir!


Best regards,
Ji Zhou
Microsoft Online Community Support

 

[Julian Ladbury]

Thanks for your suggestions about how the table corruption might come about.
With them in mind, I reviewed the code I am using to update my table, and
can now reproduce the problem using VBA. As far as I can see, the VBA code is
quite legitimate, and I would therefore be grateful if you could investigate
further to see whether this is a VBA bug.

I have uploaded another 2 files to my SkyDrive. You can use one of them run
the VBA. The other contains screenprints from my own runs. The files are
called 'Bug 30 Reproduce with VBA.doc' and 'Bug30 description #2 for
MSDN.doc'.

(By the way, I tried your suggestion of saving my original test files as
..mht and then saving back to .doc. I am sorry to say that the problem
persisted, both in the .mht file and in the saved-back .doc. I suspect you
might have been the victim of what you already noted 'The strange thing is
that sometimes I can see the issue, and sometimes it works as expected'. In
any case, it would seem sensible now to focus on the VBA issue rather than
what to do after VBA has corrupted a table!)

 

[Colbert Zhou [MSFT]]

OK. I will look into the VBA documents, research and report back in 1-2
work days. When I reply I will also notify you via email.

Have a nice weekend sir!


Best regards,
Ji Zhou
Microsoft Online Community Support

 

[Colbert Zhou [MSFT]]

Hello Julian,

After a lot of researches, I found the culprit to be a bookmark in the
first cell of the second row.

Indeed, we can see the following descriptions from the article I gave in my
previous reply,
"Corruptions can also be stored in any paragraph mark in a document; or in
an end-of-cell or end-of-row marker within a table; or in a bookmark.
(Corrupt bookmarks are very rare in Word 97 and above, unless you have been
using EndNote)."

So I remove the bookmark from the document. After that, if I execute the
VBA codes that add endnotes, the document will not be corrupted.


Best regards,
Ji Zhou
Microsoft Online Community Support

 

[Julian Ladbury]

Colbert,

Thank you for your diligence pursuing this. Two heads are always better than
one in this sort of thing!

Following your discovery, and your reiteration that 'Corrupt bookmarks are
very rare in Word 97 and above, unless you have been using EndNote', I can
now reproduce the problem to order in a New Blank Document without any VBA.
Here’s how:

1. Create a New Blank Document
2. Insert a two-row, one-column table (more than one row seems essential,
the number of columns seems not to matter)
3. Select Row 2 Cell 1
4. Insert a bookmark
5. Insert an endnote
6. Try to 'Insert Row Above' row 2; the problem occurs

Following the steps above reproduces the problem 100% of the time in both
2007 and the 2010 Beta. I have not tested other versions.

An interesting observation: if you use the Tab key after Step 5 to insert a
row at the end of the table, the problem disappears.

This seems definitely to be a hard bug in Word; I hope that the work we have
both done will help MS eradicate it.