I have several large XLA's that need to be installed in order for our
large reporting workbooks to work correctly. We used to use AddIns for
these, but we found that Excel periodically "forgets" about them once
in a while, at which point all our code stops working.

So I decided to avoid the AddIns system, and simply place the XLAs
into the XLSTART folder. This works very well, they work just like
they were loaded through AddIns.

However, this limits the XLA to a particular user account. I'd like
these XLAs to be system-wide. I tried placing them in a hand-created
XLSTART folder in C:\Documents and Settings\All Users\Application Data
\Microsoft, but it appears that Excel ignores it. Can anyone confirm
that?

If this is the case, does anyone have any alternate locations that
might work in the same fashion? I'd like to be able to just drop the
files on the machine and go.

Maury

Why not get your reporting wb to open your large addins if/as required.

In your wb's open event, or when needed

On error resume next
set wb = nothing
set wb = workbooks("myAddin.xla")
on error goto 0 ' or resume normal error handling

if wb is nothing then
set wb = workbooks.open(sFile)
end if

Regards,
Peter T


"Maury Markowitz" <(E-Mail Removed)> wrote in message
news:e476e392-2cd0-4979-b0cf-(E-Mail Removed)...
>I have several large XLA's that need to be installed in order for our
> large reporting workbooks to work correctly. We used to use AddIns for
> these, but we found that Excel periodically "forgets" about them once
> in a while, at which point all our code stops working.
>
> So I decided to avoid the AddIns system, and simply place the XLAs
> into the XLSTART folder. This works very well, they work just like
> they were loaded through AddIns.
>
> However, this limits the XLA to a particular user account. I'd like
> these XLAs to be system-wide. I tried placing them in a hand-created
> XLSTART folder in C:\Documents and Settings\All Users\Application Data
> \Microsoft, but it appears that Excel ignores it. Can anyone confirm
> that?
>
> If this is the case, does anyone have any alternate locations that
> might work in the same fashion? I'd like to be able to just drop the
> files on the machine and go.
>
> Maury

Hi Maury,
Peters suggestion would probably work best. Even better if located on a network server.

You can redefine the xlstart folder. You just need to change the path stored in the registry.
If you have users that have other files in their xlstart folder changing the registry path will probably screw them up.

John


"Maury Markowitz" <(E-Mail Removed)> wrote in message
news:e476e392-2cd0-4979-b0cf-(E-Mail Removed)...
>I have several large XLA's that need to be installed in order for our
> large reporting workbooks to work correctly. We used to use AddIns for
> these, but we found that Excel periodically "forgets" about them once
> in a while, at which point all our code stops working.
>
> So I decided to avoid the AddIns system, and simply place the XLAs
> into the XLSTART folder. This works very well, they work just like
> they were loaded through AddIns.
>
> However, this limits the XLA to a particular user account. I'd like
> these XLAs to be system-wide. I tried placing them in a hand-created
> XLSTART folder in C:\Documents and Settings\All Users\Application Data
> \Microsoft, but it appears that Excel ignores it. Can anyone confirm
> that?
>
> If this is the case, does anyone have any alternate locations that
> might work in the same fashion? I'd like to be able to just drop the
> files on the machine and go.
>
> Maury

Tell everyone to go to Tools > Options > General tab. Go to the "At startup,
open all files in" and type in the path of new "XLSTART" folder. Try that and
see how it works.
--
I am running on Office 2003, unless otherwise stated.


"Maury Markowitz" wrote:

> I have several large XLA's that need to be installed in order for our
> large reporting workbooks to work correctly. We used to use AddIns for
> these, but we found that Excel periodically "forgets" about them once
> in a while, at which point all our code stops working.
>
> So I decided to avoid the AddIns system, and simply place the XLAs
> into the XLSTART folder. This works very well, they work just like
> they were loaded through AddIns.
>
> However, this limits the XLA to a particular user account. I'd like
> these XLAs to be system-wide. I tried placing them in a hand-created
> XLSTART folder in C:\Documents and Settings\All Users\Application Data
> \Microsoft, but it appears that Excel ignores it. Can anyone confirm
> that?
>
> If this is the case, does anyone have any alternate locations that
> might work in the same fashion? I'd like to be able to just drop the
> files on the machine and go.
>
> Maury
>

On Feb 18, 3:05*pm, "jaf" <m...@here.com> wrote:
> Peters suggestion would probably work best. Even better if located on a network server.

No, this is TERRIBLE. If there is any problem, even temporary, with
the network the macros just stop working. No error like "lost
connectivity" or such, no, function calls simply report "remote
machine cannot be found". This is precisely the problem I am trying to
avoid by using XLSTART.

Furthermore, using a startup script in the wb is both slow and error
prone. For instance, if I e-mail the file to someone, there's no
guarantee it will work. Even if all you do is load the AddIn from a
local directory instead of a network one, opening Excel from another
app, like Access, fails to load the modules.

Maury

On Feb 18, 3:40*pm, Orion Cochrane
<OrionCochr...@discussions.microsoft.com> wrote:
> Tell everyone to go to Tools > Options > General tab. Go to the "At startup,
> open all files in" and type in the path of new "XLSTART" folder. Try thatand
> see how it works.

Hmmmm... any way to automate this?

Maury

I don't think you have thought that through at all, the approach is widely
used particularly for large addins, never mind.

As for your other post, look at Application.AltStartupPath

Another thing you could do is put shortcuts to your addins in a/the startup
folder.

Best approach is rethink along the lines suggested.

Regards,
Peter T

"Maury Markowitz" <(E-Mail Removed)> wrote in message
news:10f75bb5-d1bc-426f-ae3b-(E-Mail Removed)...
On Feb 18, 3:05 pm, "jaf" <m...@here.com> wrote:
> Peters suggestion would probably work best. Even better if located on a
> network server.

No, this is TERRIBLE. If there is any problem, even temporary, with
the network the macros just stop working. No error like "lost
connectivity" or such, no, function calls simply report "remote
machine cannot be found". This is precisely the problem I am trying to
avoid by using XLSTART.

Furthermore, using a startup script in the wb is both slow and error
prone. For instance, if I e-mail the file to someone, there's no
guarantee it will work. Even if all you do is load the AddIn from a
local directory instead of a network one, opening Excel from another
app, like Access, fails to load the modules.

Maury

When does Excel forget about them? You mean the addin references are there
but the XLAs are not opening? Or the Addins are getting unchecked?

Perhaps another way to go about it is to have one little add-in whose job it
is on workbook_open to open the many big add-ins. This in general seems to
be a cleaner way to get many files opened, rather than having several add-in
references which are part of one reporting solution.


--
Tim Zych
http://www.higherdata.com

"Maury Markowitz" <(E-Mail Removed)> wrote in message
news:e476e392-2cd0-4979-b0cf-(E-Mail Removed)...
>I have several large XLA's that need to be installed in order for our
> large reporting workbooks to work correctly. We used to use AddIns for
> these, but we found that Excel periodically "forgets" about them once
> in a while, at which point all our code stops working.
>
> So I decided to avoid the AddIns system, and simply place the XLAs
> into the XLSTART folder. This works very well, they work just like
> they were loaded through AddIns.
>
> However, this limits the XLA to a particular user account. I'd like
> these XLAs to be system-wide. I tried placing them in a hand-created
> XLSTART folder in C:\Documents and Settings\All Users\Application Data
> \Microsoft, but it appears that Excel ignores it. Can anyone confirm
> that?
>
> If this is the case, does anyone have any alternate locations that
> might work in the same fashion? I'd like to be able to just drop the
> files on the machine and go.
>
> Maury

Maury,
Addins that are checked (tools>addins) load on opening and are visible in the VBA editor.
There is no network activity once the wb is loaded.

John



"Maury Markowitz" <(E-Mail Removed)> wrote in message
news:10f75bb5-d1bc-426f-ae3b-(E-Mail Removed)...
On Feb 18, 3:05 pm, "jaf" <m...@here.com> wrote:
> Peters suggestion would probably work best. Even better if located on a network server.

No, this is TERRIBLE. If there is any problem, even temporary, with
the network the macros just stop working. No error like "lost
connectivity" or such, no, function calls simply report "remote
machine cannot be found". This is precisely the problem I am trying to
avoid by using XLSTART.

Furthermore, using a startup script in the wb is both slow and error
prone. For instance, if I e-mail the file to someone, there's no
guarantee it will work. Even if all you do is load the AddIn from a
local directory instead of a network one, opening Excel from another
app, like Access, fails to load the modules.

Maury