Fred,
Some non-expert ideas:
One good reason for multi-modules is variable declaration: Variables and
constants declared as "Private" at the top of a module are "module-level",
i.e., they are not recognized outside of the module in which they are
declared, so this can be a useful way of organizing and utililzing your
project's variables.
Another advantage of multi-modules is it allows you to organize your macros
according to some kind of personal scheme or theme. You may want to put all
or most functions within one module, or, perhaps, your frequently-called
special-task sub-routines, or a set of macros that, together, accomplish a
discrete part of the larger job that is the project (this dovetails with the
variable-scope idea).
When editing or creating your project, skipping back and forth between
macro's, the VBEditor remembers and returns you to the part of the 'page'
(i.e., module) that you were on when you clicked away, so this is a
convenience that saves searching and scrolling within a module. Similarly,
the text-search function of the VBEditor has the option of being module- or
project- specific, so this confers more power to a multi-module approach.
Also, if you are good at remembering which module has which parts of your
code (and you will remember better if the project is organized organically),
there is less scrolling when searching for a part of your code, if the code
is broken up into modules.
I haven't used this one much, but by exporting/saving a module, you can give
it a custom name that will appear in the module list (instead of the generic
module1, module2...) when it is imported back in.
Shockley
