Have you thought about using "application.run" instead of using the reference
and a call statement?

As long as your addin is open (and uses the same name), I bet it would work ok.

PeteCresswell wrote:

I know I'm starting to turn into a tarbaby on this subject.

All I'm trying to do is consolidate my Excel VBA into one place:
a .XLA.

Reason I want to do this is that the users will be prone to cloning my
Workbooks into many, many variations as they try different data
scenarios - and if I need to make code changes I don't want to have to
deal with tracking down and retrofitting dozens of clones.

I can make my code work (i.e. the XLS can see the .XLA routines) by
setting a Reference in the .XLS that points to the .XLA.

But what I'd much prefer to do is to use the "AddIn" feature to make
the .XLA an AddIn.

Reason: there are tools available for managing AddIns. As I do
development work on the .XLA and variations of the .XLS concurrently I
don't want tb saddled with having to remember to update my
referenec(s) every time I elevate a new version to production.

But attempting to complete this seemingly bread-and-butter task has
turned into a 3-day nightmare for me.

I've lost track of the number of man hours I've spend on it - to no
avail.

This has tb an every-day developer task - so clearly I'm missing
something.

What I want to do is separate my development code from my production
code - without having to remember to update References in the .XLS's -
preferably with one of the available add-in managers like the one
Charles Williams so kindly pointed me to at his site:
http://www.DecisionModels.com/downloads.htm

Can somebody elucidate?

--

Dave Peterson