I have been working to create a routine to format some tables with a specified number of beginning rows with .HeadingFormat to make them repeat on each page. That resulted in the fact that tables with any cells merged (mergers) vertically, the row object references are not valid. The rows must be split before using VBA to process them.

I have developed a very nice set of routines for determining if a cell is a merger (vert., horiz. or both) and can also give the user a list (cells for vert. and rows for horiz.).

Arrays are used to save the rows and cells with mergers. The arrays were intended to be used to split the cells (vert. mergers only) and remerge them after processing my table formatting.

However, I think I have encountered a bug. Some vert. merged cells cannot be split depending on the surrounding/adjacent merging. Also, when attempting to trap the error, sometimes it works and sometime not.


And, I think that some cells can't be split is also a bug. Selecting the cell, manually, and performing the split from the ribbon command works fine.

When, the error is untrappable, VBA simply displays the error description and won't branch to the On Error label and stops.

The only way to practically demonstrate this problem is to let you try it with my project file, attached.

Please remember, not everyone writes scripting the same way. I like everything as I have it except for the error trapping discrepancy when attempting to split a cell and help with that would be appreciated.

I have seen a lot of forum discussions about similar attempts to identify mergers and I have a very good one, I think.

My apologies for being so verbose.

Attached Files

TableCellMergeHacking_R04.docm (50.7 KB, 8 views)