"Chip Pearson" wrote in message
...
"Terry von Gease" wrote in message

I'll do it but I can only wonder just why would I want to do
this.

Well, I thought that you wanted to separate code from data,
putting the code in one workbook, such as personal.xls, and be
able to run that code from any other workbook. Placing "vast
tracts" of common code in personal.xls is one way to do this.

Since you say that using Application.Run is unacceptable in your
circumstances, you need another mechanism to allow VBA to find the
common code to execute. Setting a reference to the workbook
containing the code is the method you use to do this. However,
referenced workbooks and libraries must have unique names. Since a
workbook's project name defaults to "VBA Project" you need to
rename the project in order to set a reference to it.

I did all that. Unique file name, unique project name. I still can't get
Tools- References... to accept it. Is there some incantation or another
that I'm missing here or am I simply accursed?


You can then call the code in the referenced project as if it
existed in the same project -- no need for Application.Run.

Your original post asked:

Is there any way to tell Excel where to look to resolve
procedure
references?

Setting a reference is exactly how you do it. That's why you would
want to do this.

I fervently want to do this. The problem is that it's not letting me.

And just what's with this ""Document not saved" crap that keeps popping up,
or not, based on some bizarre principle unknown to me?

....deletia...

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley