Ok, so to use sub-modules (and I really like that idea), suppose I have this
construct:

Dim blnYunky as Boolean
Dim myParameter as Long
For Each Yadda In Yading To Yadong
If Bingo Then
'what do I put here to call module Fooby with a parameter?
blnYunky = MyModule(myParameter, myResult) '??
Endif

Private Function MyModule (ByRef myParameter As Long, _
myResult As Boolean) As Long
For Each rngWiggy In Range(rngBugfree(1), rngBugFree(myParameter)
'Yadda, yadda
If MySomething Then
MyResult = True
End If
Next rngWiggy
End Function

Is that the sort of thing you mean?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Joel" wrote:

Use good programming practives. Usually around 200 - 250 line of code per
module is the limit. Better than the 500 punch cards I had to use in
college. Consider how you are going to tet the code in making the decision
to have one or multiple modules.

You didn't say if you where building a subroutine or a function, but it is
always good to create sub-functions where possible.

"Dave Birley" wrote:

I said I was OLD, couldn't remember the word "module" to save my life. Not
ignorance, just a little "Halfzheimer's" <g). Non "Process" est, sed
"Module". Mea culpa <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"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