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

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

There is a limit of about 64K on the size of a module. You would export it
to a .bas file, then look at the size of the file. The limit is not
published anywhere, but appears to be a practical limit - above that you
start having problems. Beyond that, I don't believe there is any limit.
Some people create huge procedures using the macro recorder.

Use of subroutines is encouraged from a maintenance/readability standpoint.

--
Regards,
Tom Ogilvy



"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

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

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

Yes, except MyModule doesn't return anything.

"Dave Birley" wrote:

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

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

You can park them anywhere you want. VBA will find them by name, which it
has already sorted and listed in the declarations dropdown on the VBE window.
I was just wondering if you were ever in Mahe, Seychelles?

"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

«I was just wondering if you were ever in Mahe, Seychelles?» Closest I've
been was 2.5 yrs atop the Rock of Gibraltar!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"JLGWhiz" wrote:

You can park them anywhere you want. VBA will find them by name, which it
has already sorted and listed in the declarations dropdown on the VBE window.
I was just wondering if you were ever in Mahe, Seychelles?

"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

Try to place like procedure in their own modules. you can add as many module
as you want by selecting Insert - Module in the VBE. It is a good idea to
name your modules something descriptive like modSave, or modPrint. Place all
of your saving procedures in modSave and all of your printing procedures in
modPrint. YOu could have a main calling procedure that looks like this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

Crazy learning curve -- but, OTOH, because I am working on this as a Temp,
should anyone else ever try to decipher what I've cobbled together, I would
like to build it according to "standard practice". I have a shocking and
embarrassing confession to make too, I'm actually commenting every row! Of
course part of that is to help the atrophying grey cells to remember what the
Sam Hill I was thinking when I put it together in the first place <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

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

Thank you (and everyone) for all the help on this. As I am primarily a
"practical" (vs. "theoretical") learner, the example you gave was a huge
help. I really appreciate everyone's patience with me <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"JLGWhiz" wrote:

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

«then i might name the module»
I just Inserted a new Module, but I can't seem to find where I name it. Also
it Started out with "(Declarations)" As the only choice in the right drop
down,a nd "(General)" for the left (also only one). Am I supposed to be
allowed to tweak these?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

Depending what I am up to I will ususally comment every 3 to 5 lines of code.
When I did a stint temping (as you are) I commented like there was no
tommorow. Every module, every procedure, every variable and at least every 3
lines... It makes the code much more serviceable and heck you are getting
paid by the hour!!!
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Crazy learning curve -- but, OTOH, because I am working on this as a Temp,
should anyone else ever try to decipher what I've cobbled together, I would
like to build it according to "standard practice". I have a shocking and
embarrassing confession to make too, I'm actually commenting every row! Of
course part of that is to help the atrophying grey cells to remember what the
Sam Hill I was thinking when I put it together in the first place <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

«heck you are getting paid by the hour!!!»

<BWG!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Depending what I am up to I will ususally comment every 3 to 5 lines of code.
When I did a stint temping (as you are) I commented like there was no
tommorow. Every module, every procedure, every variable and at least every 3
lines... It makes the code much more serviceable and heck you are getting
paid by the hour!!!
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Crazy learning curve -- but, OTOH, because I am working on this as a Temp,
should anyone else ever try to decipher what I've cobbled together, I would
like to build it according to "standard practice". I have a shocking and
embarrassing confession to make too, I'm actually commenting every row! Of
course part of that is to help the atrophying grey cells to remember what the
Sam Hill I was thinking when I put it together in the first place <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

Empirical testing tells me I can't push my Dims or my initializations out to
a sub -- correct?

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits
End Sub

Public Sub doInits
A = 5
B = "Bingo!"
End Sub
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Try to place like procedure in their own modules. you can add as many module
as you want by selecting Insert - Module in the VBE. It is a good idea to
name your modules something descriptive like modSave, or modPrint. Place all
of your saving procedures in modSave and all of your printing procedures in
modPrint. YOu could have a main calling procedure that looks like this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

Hi Dave

No you can't, but you could initialise a set of values with
Const A as Long =5
Const B as String ="Bingo"
which could sit outside of and before your subs
--
Regards

Roger Govier


"Dave Birley" wrote in message
...
Empirical testing tells me I can't push my Dims or my initializations
out to
a sub -- correct?

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits
End Sub

Public Sub doInits
A = 5
B = "Bingo!"
End Sub
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Try to place like procedure in their own modules. you can add as many
module
as you want by selecting Insert - Module in the VBE. It is a good
idea to
name your modules something descriptive like modSave, or modPrint.
Place all
of your saving procedures in modSave and all of your printing
procedures in
modPrint. YOu could have a main calling procedure that looks like
this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will
emerge:
Where do you park the subProcedures? For example I am currently
working in
Module1 (Code). If I park my sub-procedures in the same Module,
even though I
have made the code easier to read and to debug, am I not still at
risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my
sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break
up a large
procedure into a set of small procedures is readability. You
alluded to that
in your original post. It should all fit on one screen. Debugging
is a whole
lot easier on small procedures that do a limited number of
things. My general
rule is that one procedure should do one thing. For instance it
could format
a sheet or copy some data or print one or more sheets. If I want
to do a
bunch of things then I use a main calling procedure to call my
format precdue
then copy then print. If I need to debug or modify my code it is
easy to
determine which procedure or procedures need to be modified. So
in general
you should reach the proctical limit for the size of a procedure
long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

No but you can pass the variables from one procedure to the next...

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits(A, B)
msgbox A
msgBox B
End Sub

Public Sub doInits(byref A as long, byref B as string)
A = 5
B = "Bingo!"
End Sub

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Empirical testing tells me I can't push my Dims or my initializations out to
a sub -- correct?

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits
End Sub

Public Sub doInits
A = 5
B = "Bingo!"
End Sub
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Try to place like procedure in their own modules. you can add as many module
as you want by selecting Insert - Module in the VBE. It is a good idea to
name your modules something descriptive like modSave, or modPrint. Place all
of your saving procedures in modSave and all of your printing procedures in
modPrint. YOu could have a main calling procedure that looks like this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

"If it was hard to write, it should be hard to read." -- Chip Pearson

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Tutorials and Custom Solutions
Peltier Technical Services, Inc. - http://PeltierTech.com
_______


"Jim Thomlinson" wrote in message
...
Depending what I am up to I will ususally comment every 3 to 5 lines of
code.
When I did a stint temping (as you are) I commented like there was no
tommorow. Every module, every procedure, every variable and at least every
3
lines... It makes the code much more serviceable and heck you are getting
paid by the hour!!!
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Crazy learning curve -- but, OTOH, because I am working on this as a
Temp,
should anyone else ever try to decipher what I've cobbled together, I
would
like to build it according to "standard practice". I have a shocking and
embarrassing confession to make too, I'm actually commenting every row!
Of
course part of that is to help the atrophying grey cells to remember what
the
Sam Hill I was thinking when I put it together in the first place <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will
emerge:
Where do you park the subProcedures? For example I am currently
working in
Module1 (Code). If I park my sub-procedures in the same Module, even
though I
have made the code easier to read and to debug, am I not still at
risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up
a large
procedure into a set of small procedures is readability. You
alluded to that
in your original post. It should all fit on one screen. Debugging
is a whole
lot easier on small procedures that do a limited number of things.
My general
rule is that one procedure should do one thing. For instance it
could format
a sheet or copy some data or print one or more sheets. If I want to
do a
bunch of things then I use a main calling procedure to call my
format precdue
then copy then print. If I need to debug or modify my code it is
easy to
determine which procedure or procedures need to be modified. So in
general
you should reach the proctical limit for the size of a procedure
long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

Hi Dave,

New guy on the thread. I can't see where anyone answered this. To
rename a module in VBE, press F4 (short for View - Properties). Put
your new name after (name) in place of Module1.

I find my procedures to be a little longer than they used to be. Even
with really descriptive sub names and good comments, continually
jumping between procedures made it tough to follow the flow. So I
have gravitated toward subs where the code is repeated in several
places so the code can be re-used. Examples of topics that repeat in
just about every application are changing folders, setting paths,
opening and saving files. Grouping these in a module makes it easier
to pull them into the next project and re-use the code.

One of the trade-offs to passing lots of parameters is to define
Public variables (for variable scope discussion, see Declaring
Variables in VBE Help) which can be seen from any module, or putting
Dim at the top of a module where it can be seen from any macro in the
module. Be sure to use Public and module level variable names that
you aren't going to use in a lower scope. It can be tough to debug a
problem with Public x% when you have Dim'd x% in a smaller scope.

I, too, like to keep my screen display more compact to reduce
scrolling. I tend to have three levels of comments:
' **************
' really major blocks of code
' **************

' comment applies to the next few lines

code code code code code code ' one word or phrase
Same line comments don't work if the line of code is long so that you
have to horizontal scroll to see the comment. Back in the days of
line editors, before vi and emacs, when I cound print my code on 132
column chain printers, all my comments were same line comments,
typically starting at column 81!

Also on the screen display topic, I tend to continue long code to the
next line with " _" to reduce horizontal scrolling. This especially
helps when nesting IF's and WITH's have pushed even short lines out of
sight. Literal strings can only be continued to the next line by
splitting the string, such as "Ab Cd" to "Ab" & " Cd"

These are some practices I have found handy for myself even though
they might not be "standard" coding practices.

Carl

On May 29, 12:07 pm, Dave Birley
wrote:
«then i might name the module»
I just Inserted a new Module, but I can't seem to find where I name it. Also
it Started out with "(Declarations)" As the only choice in the right drop
down,a nd "(General)" for the left (also only one). Am I supposed to be
allowed to tweak these?
--
Dave
Temping with Staffmark
in Rock Hill, SC

What a perfect example for me to play with and hack. We "practical learners"
really need this sort of thing, and this is just great!

You da MAN!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

No but you can pass the variables from one procedure to the next...

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits(A, B)
msgbox A
msgBox B
End Sub

Public Sub doInits(byref A as long, byref B as string)
A = 5
B = "Bingo!"
End Sub

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Empirical testing tells me I can't push my Dims or my initializations out to
a sub -- correct?

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits
End Sub

Public Sub doInits
A = 5
B = "Bingo!"
End Sub
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Try to place like procedure in their own modules. you can add as many module
as you want by selecting Insert - Module in the VBE. It is a good idea to
name your modules something descriptive like modSave, or modPrint. Place all
of your saving procedures in modSave and all of your printing procedures in
modPrint. YOu could have a main calling procedure that looks like this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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

Awesome stuff, Carl. Just what I was looking for. I made my initial move into
geekdom around age 50, so I have deliberately avoided getting too catholic in
my selection of languages to master. For most of 25 years or so I worked in
the xBase/VFP genre. The result is that I have a very solid grounding in
programming principles, many of which are universal, but picking up the
vocabulary and syntax is about as complex as when I was learning Swahili (in
1957). The brain says "House boy, bring food", but the mouth needs to say
"Mvulana, lete chakula!".

I have appreciated the way that folks here are so supportive, and
non-judgemental.
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Carl Hartness" wrote:

Hi Dave,

New guy on the thread. I can't see where anyone answered this. To
rename a module in VBE, press F4 (short for View - Properties). Put
your new name after (name) in place of Module1.

I find my procedures to be a little longer than they used to be. Even
with really descriptive sub names and good comments, continually
jumping between procedures made it tough to follow the flow. So I
have gravitated toward subs where the code is repeated in several
places so the code can be re-used. Examples of topics that repeat in
just about every application are changing folders, setting paths,
opening and saving files. Grouping these in a module makes it easier
to pull them into the next project and re-use the code.

One of the trade-offs to passing lots of parameters is to define
Public variables (for variable scope discussion, see Declaring
Variables in VBE Help) which can be seen from any module, or putting
Dim at the top of a module where it can be seen from any macro in the
module. Be sure to use Public and module level variable names that
you aren't going to use in a lower scope. It can be tough to debug a
problem with Public x% when you have Dim'd x% in a smaller scope.

I, too, like to keep my screen display more compact to reduce
scrolling. I tend to have three levels of comments:
' **************
' really major blocks of code
' **************

' comment applies to the next few lines

code code code code code code ' one word or phrase
Same line comments don't work if the line of code is long so that you
have to horizontal scroll to see the comment. Back in the days of
line editors, before vi and emacs, when I cound print my code on 132
column chain printers, all my comments were same line comments,
typically starting at column 81!

Also on the screen display topic, I tend to continue long code to the
next line with " _" to reduce horizontal scrolling. This especially
helps when nesting IF's and WITH's have pushed even short lines out of
sight. Literal strings can only be continued to the next line by
splitting the string, such as "Ab Cd" to "Ab" & " Cd"

These are some practices I have found handy for myself even though
they might not be "standard" coding practices.

Carl

On May 29, 12:07 pm, Dave Birley
wrote:
«then i might name the module»
I just Inserted a new Module, but I can't seem to find where I name it. Also
it Started out with "(Declarations)" As the only choice in the right drop
down,a nd "(General)" for the left (also only one). Am I supposed to be
allowed to tweak these?
--
Dave
Temping with Staffmark
in Rock Hill, SC

Or, seen another way, "If the Project's late, obfuscate!"
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jon Peltier" wrote:

"If it was hard to write, it should be hard to read." -- Chip Pearson

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Tutorials and Custom Solutions
Peltier Technical Services, Inc. - http://PeltierTech.com
_______


"Jim Thomlinson" wrote in message
...
Depending what I am up to I will ususally comment every 3 to 5 lines of
code.
When I did a stint temping (as you are) I commented like there was no
tommorow. Every module, every procedure, every variable and at least every
3
lines... It makes the code much more serviceable and heck you are getting
paid by the hour!!!
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Crazy learning curve -- but, OTOH, because I am working on this as a
Temp,
should anyone else ever try to decipher what I've cobbled together, I
would
like to build it according to "standard practice". I have a shocking and
embarrassing confession to make too, I'm actually commenting every row!
Of
course part of that is to help the atrophying grey cells to remember what
the
Sam Hill I was thinking when I put it together in the first place <g!
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Susan" wrote:

just stash 'em in another module with "public" before them - then any
module (or userform code) can call them.
while you can't name a module the same name as the sub inside it, i
try to name it something similar so i can keep track of them.

so if a module contains:

sub find_last()
end sub

then i might name the module
find_last_integer

or something like that.
susan


On May 29, 11:46 am, Dave Birley
wrote:
This is all wonderful for my learning curve. Now my naivitee will
emerge:
Where do you park the subProcedures? For example I am currently
working in
Module1 (Code). If I park my sub-procedures in the same Module, even
though I
have made the code easier to read and to debug, am I not still at
risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC



"Jim Thomlinson" wrote:
To expand on what Tom said. One of the biggest reasons to break up
a large
procedure into a set of small procedures is readability. You
alluded to that
in your original post. It should all fit on one screen. Debugging
is a whole
lot easier on small procedures that do a limited number of things.
My general
rule is that one procedure should do one thing. For instance it
could format
a sheet or copy some data or print one or more sheets. If I want to
do a
bunch of things then I use a main calling procedure to call my
format precdue
then copy then print. If I need to debug or modify my code it is
easy to
determine which procedure or procedures need to be modified. So in
general
you should reach the proctical limit for the size of a procedure
long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson

"Dave Birley" wrote:

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- Hide quoted text -

- Show quoted text -

Just reporting back -- I have now modularized the whole shebang, and it has
gone from being a monster to being "my friend". I have finally been able to
see clearly where the problems exist, and, at the same time know that certain
modules work just fine and can be left untouched.

One tiny question -- I followed your example to the letter, hence..

Public Sub doInits(byref A as long, byref B as string)

...I copied the "Public", and identified all parameters as "ByRef". (FWIW I
also finally found where the "Name" Window was hiding so I could rename the
modules). Should I always use all those components ("Public", "ByRef") or are
there times when one or other could be dropped. Also, if I add some Dims in
the sub-process, do they exist as Local only, and expire on exit from the
module? IOW, if it aquires a value of, say, 100 the first time I visit the
sub-process, when I come back again it will be uninitialized, right?

One thing I learned the hard way is that the parameters MUST be in the same
order "going" and "coming", Heck, I should have know that -- it is the way
parms work in all languages.
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

No but you can pass the variables from one procedure to the next...

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits(A, B)
msgbox A
msgBox B
End Sub

Public Sub doInits(byref A as long, byref B as string)
A = 5
B = "Bingo!"
End Sub

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

Empirical testing tells me I can't push my Dims or my initializations out to
a sub -- correct?

Public Sub myProject
Dim A As Long
Dim B As String

Call doInits
End Sub

Public Sub doInits
A = 5
B = "Bingo!"
End Sub
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

Try to place like procedure in their own modules. you can add as many module
as you want by selecting Insert - Module in the VBE. It is a good idea to
name your modules something descriptive like modSave, or modPrint. Place all
of your saving procedures in modSave and all of your printing procedures in
modPrint. YOu could have a main calling procedure that looks like this

Public Sub DoStuff
call modPrint.PrintPage1
call modSave.SaveAsNewFile
end sub

Easy to follow and easy to debug if something goes wrong...
--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

This is all wonderful for my learning curve. Now my naivitee will emerge:
Where do you park the subProcedures? For example I am currently working in
Module1 (Code). If I park my sub-procedures in the same Module, even though I
have made the code easier to read and to debug, am I not still at risk of
hitting that size limit previously mentioned by Tom?

Otherwise, how do I initiate a new Module to stash my sub-Procedures?
--
Dave
Temping with Staffmark
in Rock Hill, SC


"Jim Thomlinson" wrote:

To expand on what Tom said. One of the biggest reasons to break up a large
procedure into a set of small procedures is readability. You alluded to that
in your original post. It should all fit on one screen. Debugging is a whole
lot easier on small procedures that do a limited number of things. My general
rule is that one procedure should do one thing. For instance it could format
a sheet or copy some data or print one or more sheets. If I want to do a
bunch of things then I use a main calling procedure to call my format precdue
then copy then print. If I need to debug or modify my code it is easy to
determine which procedure or procedures need to be modified. So in general
you should reach the proctical limit for the size of a procedure long before
you hit an technical limit... Just my 2 cents.

--
HTH...

Jim Thomlinson


"Dave Birley" wrote:

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