We have a lot of code that is essentially "universal", that is, it could
easily be run in Excel or Access. In fact the vast majority of our code is
like this, we use the applications largely as a display system.

Is there some way to isolate this code into a stand-alone library of some
sort, and use it in any application we choose? If we want to use it in Excel
we have the .xla, but I don't see a format that can be used for Office app?

Maury

MS used to have a product called Code Librarian that shipped with
the Developer's Edition of Office, which allowed you to organize
source code in a central library. This was a source code
organizer; you couldn't directly run the code in the library, you
cut and pasted in to host applications. I don't know what
happened to Code Librarian, I don't think it ships in any version
of Office 2003.

You could create an ActiveX DLL (using VB6) containing all your
common code, and then instantiate that object in your host
applications.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com




"Maury Markowitz"
wrote in message
...
We have a lot of code that is essentially "universal", that is,
it could
easily be run in Excel or Access. In fact the vast majority of
our code is
like this, we use the applications largely as a display system.

Is there some way to isolate this code into a stand-alone
library of some
sort, and use it in any application we choose? If we want to
use it in Excel
we have the .xla, but I don't see a format that can be used for
Office app?

Maury

"Chip Pearson" wrote:
You could create an ActiveX DLL (using VB6) containing all your
common code, and then instantiate that object in your host
applications.

This sounds like the easiest solution.

The reason I'm doing all of this is because MS's file locking logic is
driving us absolutely batty. We wrote most of the code in a XLA, but then the
first person to come to work in the morning and open a spreadsheet means we
can't work on it any more.

I'm curious if you have any direct experience with using DLL's in the same
fashion. If we go this route, will Excel simply be locking the DLL instead of
the XLA and we'll be right back where we started?

Maury

I don't believe so. Each running instance of Excel will
instantiate its own private copy of the DLL.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com


"Maury Markowitz"
wrote in message
...
"Chip Pearson" wrote:
You could create an ActiveX DLL (using VB6) containing all
your
common code, and then instantiate that object in your host
applications.

This sounds like the easiest solution.

The reason I'm doing all of this is because MS's file locking
logic is
driving us absolutely batty. We wrote most of the code in a
XLA, but then the
first person to come to work in the morning and open a
spreadsheet means we
can't work on it any more.

I'm curious if you have any direct experience with using DLL's
in the same
fashion. If we go this route, will Excel simply be locking the
DLL instead of
the XLA and we'll be right back where we started?

Maury

"Chip Pearson" wrote:

I don't believe so. Each running instance of Excel will
instantiate its own private copy of the DLL.

Ok, I'll go this route then!

Maury