Here is a sample of how modular code can work in VBA. The first one is the
control
sub which calls the others in the order they need to run. The sub routines
are listed in order but they don't have to be. They can be anywhere in the
standard module.

Sub addErase()
addCellValue
moveCellVaule
changeCellValue
delCellValue
End SuB

Sub addCellValue()
Range("A1") = "Hello"
End Sub

Sub moveCellValue()
Range("A1").Value.Cut Range("B1")
Application.CutCopyMode = False
End Sub

Sub changeCellValue()
Range("B1").Value = Range("B1").Value & "World"
End Sub

Sub delCellValue()
Range("B1").Clear
ThisWorkbook.Save
ThisWorkbook.Close
End Sub


"Dave Birley" wrote:

I'm building a Macro that is growing "like Topsy". At the moment it is 145
lines long, and will increase by about 50% from there when done. Because I'm
an old (really OLD<g) VFP programmer, my thinking and development pattern is
shaped by that experience.

So, is it considered bad form to have a macro get large? I recall that in
C++ the recommendation was to try to hold a process to one screenful where
possible, and then build a "parent" process that called the segments in
sequence. However my macro consists of a series of nested For Loops that goes
five or six levels deep.

Just wondering -- and trying to learn <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC