"Howard Kaikow" wrote in message
...
"Peter T" <peter_t@discussions wrote in message
...
"Howard Kaikow" wrote in message
...
When you run the code, are you running via VB 6, or are you running in
Excel?

Ah, you are aitomating Excel from Word.
That is likely significantly different than automating from VB 6.

Like I said, not significantly different at all in Word vs VB6, in fact very
similar as I would have expected. Some things of course work faster in
compiled VB, though not much difference working with excel objects, even in
the IDE (FWIW I've noticed an in process dll can be faster, even than the
same dll used as a Com addin).

Not to mention AV software might poke its nose in differently.

No idea about that.


Also, I forget to mention that while I am running my "real" program, I
outputing progress both
to a listbox and a text file.

However, the latest version of hte code, used inline, rather than via sub,
eliminates a lot of the overhead, e.g., it does not do the mergearea until
after everything else is done, and uses a Union which is clearly faster.

In my original example, I was processing 1 chunk at a time, moving down a
column.
In the "real" program, I've changed that to process along rows.

Code snippett is given below.

I take it you didn't try the litte test I posted (which demonstrates the
gain to be had by disabling screenupdating in an invisible instance depends
on what you are doing to sheet and cells). Your snippet is sort of simlar to
the second of my two tests which showed only a small gain to be had by
disabling screenupdating in an invisible instance.

In Word. I 've just repeated in VB6 and got similar timings. However,
seems
it depends on what you are doing as to whether there's a significant
speed
gain with screenupdating disabled when excel is not visible.

I did extensive testing of Screenupdating in Word over the years, there is
a
significant
improvement, using the Range object with Word, more so if SCreenupdating
is
not enabled.
Of course the document is not visible.

I didn't test anything relating to Word and Word's Range object, other than
automating Excel in Word.

IN my case, enabling screenupdaing adversely affects performance, no need
to
test otherwise.

Of course go with whatever works best with your overall scenario. Just
looking at the snippet below I'd bet it would be a tad faster with
screenupdating disabled in an invisible instance. Other things you are doing
might negate that.


k = count Mod PerRow
'If symbols are used, no need to adjust rowheight
If Not bUseSymbols Then
Select Case k
Case 1
Set rng = .Offset(r, 0)
Case 2
Set rng = Union(.Offset(r, 0), .Offset(r, 2))
Case 3
Set rng = Union(.Offset(r, 0), .Offset(r, 2),
.Offset(r, 4))
Case 4
Set rng = Union(.Offset(r, 0), .Offset(r, 2),
.Offset(r, 4), .Offset(r, 6))
End Select
SourceWidth = .Offset(r, 0).Columns(1).ColumnWidth
MergedAreaWidth = 2 * SourceWidth
With rng
.ColumnWidth = MergedAreaWidth
.WrapText = vbTrue
With .Rows(1)
.EntireRow.AutoFit
.RowHeight = .RowHeight
End With
.ColumnWidth = SourceWidth
End With
End If
For j = 1 To k
n = (j - 1) * 2 ' I yam merging 2 cells
.Application.Range(.Offset(r, n), .Offset(r, n +
1)).MergeCells = vbTrue
Next j