Clearing the 'Undo' memory cache in Word to avoid sluggish behavio

[Dave]

Hello,

I have to work with approximately 1,000 page Word documents (talk about
pushing things to the limit). I often have to make numerous find&replace
operations (in fact I have them all saved in macros to run consecutively and
automatically).

The problem is that Word seems to run out of memory and evens warns of
insufficient memory. I do not need the 'Undo' feature of Word in these
circumstances. How can I turn off 'Undo"? Will that solve my problem? What
I'd like to do is include macro code to clear the 'Undo' memory cache after
each find&replace operation. Is this possible?

Thanks for any and all expert opinions on this!

 

[Jay Freedman]

Hi Dave,

It isn't possible to turn off Undo, but you can clear its cache.

Somewhere in your processing loop -- say, just before or after each
F&R -- include the statement
ActiveDocument.UndoClear

 

[Dave]

Jay,

Thanks, your suggestion seems like it will be very helpful with respect to
the Find & Replace operations.

However, in general, with 1,000 + page documents in MS Word. The program is
still rather unresponsive (actually, slow as mollassas). Does anybody else
have any other tips to help speed things along. We do not have any graphics
nor embedded fonts or anything else unusual with the documents that I am
aware of. I can think of three areas to comment on:

1) Things I can do within Word itself (i.e. set certain options)

2) Things I can do within my operating system itself (i.e. set Windows XP
settings)

3) Things I can do to locate and fix the performance bottleneck with my
computer hardware itself. I.e. processor, ram, etc. (In my case I have a
new Dell 2.8 GHz with 500+ MB of RAM, so I am not sure what would help
further. I.e. a new machine with dual processor, a mainframe .... ? Since
this is a major headache for our business, getting the hardware right is an
option, except perhaps for the mainframe

Thanks everybody!

 

[Jay Freedman]

Hi Dave,

The biggest single thing you can do to speed up the macro is this: if you're
using the Selection object at all, use a Range object instead wherever
possible. When you move or manipulate the Selection object, you're affecting
the actual selection on the screen and causing Word to redraw and possibly
to repaginate. With a Range object, the screen is unaffected. You can also
set ScreenUpdating to False at the start of the macro and set it back to
True at the end; this won't turn off all redrawing, but it will help.

If you mean that the slowness is in the general editing interface and not
just the macro, the issue is a lot murkier. Does the document contain
tables, especially long ones that extend over several pages? That's one of
Word's poor performance hits -- see
http://word.mvps.org/FAQs/TblsFldsFms/FastTables.htm for some tips.

Make sure your printer driver is the latest available version. Word puts
heavy demands on it.

 

[Dave]

Jay,

Thanks for your additional suggestions. I will implement them but do not
yet know how. Lets say I am looking at the macro in edit view.

First, how do I go about using the 'Range object' rather than the 'Selection
object'. My macros were created automatically in the Word macros recorder
wizard. However, I am not afraid to edit them by hand if necessary.

Likewise, how do I set 'ScreenUpdating' to either True or False within a
macro?

The slowness I experience can be attrributed to both the situations, i.e.
when I run the macros, I believe that I am overloading the Undo cache and
causing Word to grind to a halt. Separately, I believe that the sheer size
of the documents are causing Word to respond very slowly as well. I am not
using tables in this document, however, I have a large index at the end of
the document with over 3,400 index entries. Is the index a 'form' of table?
I think that the document it is still unresponsive even after deleting the
index and also I do not percieve any performance problems when printing the
document. I really do appreciate your help! You could really solve a major
productivity issue in my workday life, thanks!

Best regards,

Dave

 

[Jonathan West]

Jay,

Thanks for your additional suggestions. I will implement them but do not
yet know how. Lets say I am looking at the macro in edit view.

First, how do I go about using the 'Range object' rather than the
'Selection
object'. My macros were created automatically in the Word macros recorder
wizard. However, I am not afraid to edit them by hand if necessary.

The way to go about this is to include the following 2 lines at the start of
the macro

Dim myRange as Range
Set myRange = Selection.Range

Then, everywhere else in your macro, replace "Selection" with "myRange". if
anywhere in your macro uses "Selection.Range", replace the whole of that
with just myRange.

In most cases, when you run the macro, it will work in just the same way,
but faster and without all the moving about. If you want the macro to finish
with the selection point moved to the same final location, but this line at
the end of the macro.

myRange.Select

There are a small number of things you can do with the Selection that you
can't do with a Range. if you trip up on one of these, post back and we will
help you find a workaround.

Likewise, how do I set 'ScreenUpdating' to either True or False within a
macro?

At the start of the macro, add this line

Application.Screenupdating = False

At the end, add this line

Application.Screenupdating = True

The slowness I experience can be attrributed to both the situations, i.e.
when I run the macros, I believe that I am overloading the Undo cache and
causing Word to grind to a halt.

Regularly do the following within the macro and see if it speeds up

ActiveDocument.UndoClear

Separately, I believe that the sheer size
of the documents are causing Word to respond very slowly as well. I am
not
using tables in this document, however, I have a large index at the end of
the document with over 3,400 index entries. Is the index a 'form' of
table?

No it is a field.

I think that the document it is still unresponsive even after deleting the
index and also I do not percieve any performance problems when printing
the
document. I really do appreciate your help! You could really solve a
major
productivity issue in my workday life, thanks!

If you normally work in Print view (Page view), you might also want to try
adding this to the macro, just after the Application.Screenupdating = False
statement.

ActiveDocument.ActiveWindow.View.Type = wdNormalView

and add this at the end, just before you turn screenupdating back on again

ActiveDocument.ActiveWindow.View.Type = wdPrintView

What this does is put the document into Normal view for the duration of the
macro. Normal view often works quite a bit faster as the display doesn't
have to bother so much with repagination and working out the current
contents of the headers & footers.

 

[Jay Freedman]

Thanks, Jonathan, for picking up the thread.

Dave, I'll add only one note: Where I said you should check for an
updated printer driver, I'm not referring just to printing. Word
communicates with the printer driver of the currently selected printer
constantly, asking for the size and spacing of the characters as the
printer will render them. That's how it's able to display on screen
(almost) exactly what will print. If the driver is slow or buggy,
Word's editing speed will suffer.

 

[JB]

Thanks, Jonathan, for picking up the thread.

Dave, I'll add only one note: Where I said you should check for an
updated printer driver, I'm not referring just to printing. Word
communicates with the printer driver of the currently selected printer
constantly, asking for the size and spacing of the characters as the
printer will render them. That's how it's able to display on screen
(almost) exactly what will print. If the driver is slow or buggy,
Word's editing speed will suffer.

Hi Guys,

This has been an intersting thread for me as most of the code I've
written in the past uses selection and relies heavily on moveleft,
moveright, movedown, typetext, homekey and document.paragraphs.item(x)
to manipulate my docs.

These of course don't work with selection.range, any views on how I can
change this as I'd like to make my code a damd sight quicker than it is
just now?

Cheers

J

 

[Jonathan West]

Hi Guys,

This has been an intersting thread for me as most of the code I've written
in the past uses selection and relies heavily on moveleft, moveright,
movedown, typetext, homekey and document.paragraphs.item(x) to manipulate
my docs.

The Move, MoveStart and MoveEnd methods can be used as a replacement for
MoveRight and MoveLeft.

InsertAfter can be used in place of TypeText

Move can usually be used in place of Homekey.

These of course don't work with selection.range, any views on how I can
change this as I'd like to make my code a damd sight quicker than it is
just now?

You might also be able to consider the following facts which might help you
speed up your code by thinking in a fundamentally different way about how
you design it.

1. There is only one Selection, but you can have as many Range object
variables as you like, all active at the same time.

2. Almost everything about a document has a Range property, which can be
assigned to a Range object variable or manipulated directly

3. You can iterate through many collections of objects within a Word
document such as Paragraphs) each of which has a Range property which can
then be manipulated.

4. You can apply the Find method to a Range when doing a find & replace
operation.

5. Because of all these things, you don't necessarily need to run your VBA
code by moving either the Selection or a single range around all over the
place. It may well be that there are other quicker ways of identifying the
location of your next action.

 

[Julian]

Hi Dave,

Just spotted the thread...

I also have a very large document ~600 pages - no indexes but ~4,000
comments - organised in 16 small and 16 large page-spanning tables...

I have a lot of document manipulation code and have found that using
..item(i) on any collection is exponentially slow... I guess that Word
internally starts at one and counts through until it finds the item you want.
There is a much better way.

(NB the following examples haven't been coded and tested, but you get the
idea I hope)

If at all possible, instead of something something like this

for i = 1 to aDoc.paragraphs.count
aDoc.paragraphs(i).property = X
next

try to initialise an object of the type you wish to work on and then use
..next, e.g.

dim myPara as Paragraph

(of course you can work on (declaration types in brackets): ranges (Range),
tables (Table), rows (Row), cells (Cell)... whatever is most convenient for
your purpose)

myPara = aDoc.paragraphs(1) ' point at the beginning
do while not myPara is nothing ' exit when .next finds nothing
myPara.property = X ' do your stuff here
set myPara = myPara.next ' get the next item
loop

Also, if you find yourself looking for a particular character in a string
using instr(...) a lot, you will get a significant performance boost (2x)
from using SPLIT with the required character as the "split" marker... and
then checking the size of the resulting array...

A lot of Find/Replaces will be slowed slightly if you merely copy what the
macro recorder produces... it records many option values that you do not
change from search to search: if possible, set them once and then focus only
on the find/replace text and any qualifiers as necessary.

NB .undoclear also gets rid of the ~wrlXXXX.tmp files which is often handy!
(The MS documentation on what these files are is still probably wrong)

I hope this is of help...

Julian