Practical Macro Size Limit?

[Guest]

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

 

[Jon Peltier]

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

- Jon

 

[Carl Hartness]

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

 

[Guest]

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!

 

[Guest]

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

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

 

[Guest]

Or, seen another way, "If the Project's late, obfuscate!"

 

[Guest]

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.