Please ignore the moronic post above.  Due to a massive brain
flatuation, I was convinced that the No Class method worked.  It
doesn't.

Sorry for wasting your time.

That is a very good question to ask.

First of all, there are some people who are so enamoured of classes that
they believe you should never ever write purely procedural code and that
*everything* should be a class. They are attached to that position with a
fervour that borders on the religious. If that is an arrangement that
happens to work for them, all well and good. Their certainty can be
infectious, but it is wiser to avoid it and look at the actual evidence.

For simpler tasks (which, let us be blunt, includes the vast majority of
Word macros) procedural code is perfectly adequate. There are very few cases
where my answer to a question in these groups starts with the words "first,
create a class module".

So it is worth looking at what classes are good for.

Of course, you *use* classes all the time, you just don't think of them as
such. The whole of the Word object model is an intricate interlinked series
of classes. The Application object is a class, which has lots of properties
and methods and events. One of those properties is the ActiveDocument
property which is a Document class, again with its own set of properties,
methods and events. You probably haven't been thinking of them as classes
because they aren't written in VBA and you can't see the code, but the way
you use them is almost exactly the same as how you would use your own
custom-built class.

This gives us a clue as to when it would be useful to write a class. The key
is when you are likely to want to re-use the code in a variety of projects
and different ways.

Properties of a class can look on the surface much the same as items in a
user-defined type. The difference is that with a class, you can if you
choose have a change to one property trigger a change to others. For
instance, in the PageSetup object in Word, if you set the PageHeight
property to be some value, the PageSize property is automatically set to
Custom, rather than A4 or Letter or whatever it was before. You can do the
same sort of thing in the property procedures of your own class module.

Events are also potentially very useful things to have. An event is
essentially a way of saying "tell anybody who is listening that xyz has
happened, and wait until they have done whatever they need to do as a
result". It may be that other process is listening to that event, in which
case the code in the class carries on immediately. This gives you great
flexibility on how you use a class, once you have taken the trouble to
create it.

I don't often write classes, but I am a regular consumer of them, and owe a
considerable debt of gratitude to Karl for some of his published classes
which I use on a regular basis. Almost every commercial project I do makes
use of one or more of his Drvinfo, FileInfo, kpIni, NCMetrics, PrnInfo,
RegSettings and StrBldr code samples, all of which make use of class
modules. RegSettings and NCMetrics are used in almost everything I do, the
others are used as needed. (see http://vb.mvps.org/samples/ for the list of
Karl's samples)

If you want a tutorial on how to create classes (I have been concentrating
in this post on "why" rather than "how"), take a look at these two excellent
articles by Ken Getz and Mike Gilbert. It appears they are no longer
available on the Microsoft website, but the Wayback Machine rides to the
rescue!

Class Modules: Simplify and Accelerate Your Development Processes
http://web.archive.org/web/20050306011820/http://www.microsoft.com/OfficeDev/Art
icles/classmod.htm

Advanced Class Modules
http://web.archive.org/web/20050306005832/http://www.microsoft.com/OfficeDev/Art
icles/AdvClMod.htm