Transparent .XLA?
 

Take this in the context of a total noob's groping around.

Looks to me like .XLA's (or, at least, their use) are
user/PC-specific and not application/spreadsheet-specific.

i.e. If user Smith is able to use it on his desktop PC, he may
not be able to use it with the same spreadsheet on his laptop.

i.e. For a spreadsheet to be able to use code in Whatever.xla,
each user's MS Office installation has tb configured to point to
it as an Add-In.

If I'm correct so far, I'm looking for a way to deploy 70+
identical .XLS files to 70+ different users but have all 70+
..XLS' use the same code module - so if we need to change the code
we're not up a creek.

We can live with the .XLA living on a LAN drive (i.e. a user
working offline cannot get to it).

Any solution that requires anybody to do anything on the user's
PC is out of the question. It has tb 100% transparent.

The first thing that comes to my mind is to have each .XLS'
Workbook_Open event somehow check to see if the user's PC/MS
Office has an Add-In pointing to our .XLA and, if not, create one
in such a way that it points to the common version on a LAN
server without copying it to C:\Program Files\WhereverAddinsLive

The second thing that comes to mind is doing the same check to
see if there's an Add-In and creating one if not - but pointing
it to the user's C: drive and unconditionally copying the .XLA to
somewhere on the user's C: drive if the LAN is available, and
just quietly not doing so if the LAN is not available. Seems
like this would give a little more portability, yet still let us
push changes down to each user.


Are either of these "good practice"?

If not, can somebody suggest something?
--
PeteCresswell

Transparent .XLA?
 

"The first thing" is definitely the way to go.
John Walkenbach has a great chapter on Add-ins that should get you there...
Chapter 21 in the 2003 edition of 'Excel 2003 Power Programming with VBA'.

http://www.amazon.com/exec/obidos/IS...alkassociateA/

--
Hope this helps.
Thanks in advance for your feedback.
Gary Brown


"(PeteCresswell)" wrote:

Take this in the context of a total noob's groping around.

Looks to me like .XLA's (or, at least, their use) are
user/PC-specific and not application/spreadsheet-specific.

i.e. If user Smith is able to use it on his desktop PC, he may
not be able to use it with the same spreadsheet on his laptop.

i.e. For a spreadsheet to be able to use code in Whatever.xla,
each user's MS Office installation has tb configured to point to
it as an Add-In.

If I'm correct so far, I'm looking for a way to deploy 70+
identical .XLS files to 70+ different users but have all 70+
..XLS' use the same code module - so if we need to change the code
we're not up a creek.

We can live with the .XLA living on a LAN drive (i.e. a user
working offline cannot get to it).

Any solution that requires anybody to do anything on the user's
PC is out of the question. It has tb 100% transparent.

The first thing that comes to my mind is to have each .XLS'
Workbook_Open event somehow check to see if the user's PC/MS
Office has an Add-In pointing to our .XLA and, if not, create one
in such a way that it points to the common version on a LAN
server without copying it to C:\Program Files\WhereverAddinsLive

The second thing that comes to mind is doing the same check to
see if there's an Add-In and creating one if not - but pointing
it to the user's C: drive and unconditionally copying the .XLA to
somewhere on the user's C: drive if the LAN is available, and
just quietly not doing so if the LAN is not available. Seems
like this would give a little more portability, yet still let us
push changes down to each user.


Are either of these "good practice"?

If not, can somebody suggest something?
--
PeteCresswell