View Single Post
  #1   Report Post  
Posted to microsoft.public.excel.programming
Maury Markowitz[_2_] Maury Markowitz[_2_] is offline
external usenet poster
 
Posts: 119
Default XLA development best practices

I work in a multi-user environment with a large amount of VBA code in
a monolithic XLA located on one of our fileservers. This is causing
all sorts of problems, and I'm looking for input on how to address
some of them.

To start with, having all the code in one large XLA makes maintenance
annoying, and the save and load times of the spreadsheets that use
them are way too high. I'd like to break this up into different parts,
the code is highly orthogonal so this should be easy to do.

However, since VBA can't easily call from one XLA to another, this
becomes extremely problematic. How have you all dealt with multi-XLA
code?

Another problem is that Excel seems to randomly remember or forget
XLA's in the AddIns list. This is especially common if the network
goes down, even for a second. Now Excel thinks the XLA is loaded, but
every attempt to call it fails with a different error each time. In
other cases Excel has the AddIn checked on, but the XLA is not
actually loaded. In still other cases the opposite occurs, the AddIn
shows that it's not loaded, but it is. In all of these cases there's
no simple solution to get things working about.

So how do you all deal with these sorts of issues? Do you copy the
XLA's to the user's machines? If so, does anyone have useful code for
finding the XLA folder? Is there some way of using XLA's reliably that
doesn't make the AddIn system see it. Any other tricks?

Maury