"Howard Kaikow" wrote in message
...
Bye thee waye:

I have to process RowHeights separately from MergeCells, so I have two
approaches.

First, I determine the Areas for each row that will contain merge cells.
Each such row will have up to, currently, 4 such areas.
I then do the RowHeight adjustment,

I then have 2 choices on WHEN to do the MergeCells.

1. I can do it row by row just after I adjust rowheight. This has the
advantage of eliminating the area string length issue,
but requires extra merge operations.

2. Create an area string that has all the cells to be merged and do the
merge in one operation. This should be faster
than doing separate merges, but requires me to address the length of the
area string

My guess is you have several more choices. Don't know but might be worth
while doing all the calculation stuff first, incl row heights on a per row
basis. Store address or range objects to do merge's later. Might be worth
testing if faster to do the merges on a per column basis vs per row
(probably not).

I don't see keeping track of the string length a problem. In another thread
you said something about string conc as being slow but relative to anything
to do with cells it's probably trivial.

Regards,
Peter T