Either put it in an addin, set a reference to the project that contains the
macro, or use Application.Run.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my addy)



"Rick" wrote in message
...
Bob: One last thing, How do I create a called public macro, so that
different pgms can call it.

Thanks to all who have contributed information.


"Bob Phillips" wrote:

IMO you should always declare, explicitly stating whether you want it to
be
Private or Public.

--
---
HTH

Bob


(there's no email, no snail mail, but somewhere should be gmail in my
addy)



"Rick" wrote in message
...
Thank you all for the information: Now how should one construct the
module?
What should be declared Private vs not declared at all, just sub
name(parms)?

"Jim Thomlinson" wrote:

In addition to what everyone else has said there is a programming
concept
called encapsulation. The underlying rule is to keep everything as
private
and stand alone as possible. The more subs and variables you make
public
the
more things you need to consider when something goes wrong. By keeping
things
private things stay a lot neater and tidier. It also makes things a
lot
easier to modify down the road. For example if you wnat to modify a
sub
that
is private then you only need to look at the other subs in the same
module to
see if your changes will cause a problem elsewhere. If however the
same
sub
was declared public then you need to look at all of the code in the
entire
project to confirm that there is no conflict. That is a real waste of
time if
you did not use the sub outisde of the current module.
--
HTH...

Jim Thomlinson


"Rick" wrote:

When is it correct to declare a sub Public vs Private? What is the
advantage?