Hello All,

The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.

I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
HKCU\software\microsoft\office\14.0\excel\Options: OPENn
to the .xlam file that is the add in. (If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.

This worked in the beta.

But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.

(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. 100s of events per second
when Excel is just sitting there! During an add in install it opens
the add in file dozens of times.)

Any ideas as to what happened would be greatly appreciated. Many
people will have this problem.

A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. Make the .xlam the top level. (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) Then the addin appears in the list, but still needs to be
manually enabled. The add ins list is hard for some users to find,
being four clicks from the top.

Anthony

Anthony Berglas formulated on Sunday :
Hello All,

The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.

I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
HKCU\software\microsoft\office\14.0\excel\Options: OPENn
to the .xlam file that is the add in. (If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.

This worked in the beta.

But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.

(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. 100s of events per second
when Excel is just sitting there! During an add in install it opens
the add in file dozens of times.)

Any ideas as to what happened would be greatly appreciated. Many
people will have this problem.

A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. Make the .xlam the top level. (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) Then the addin appears in the list, but still needs to be
manually enabled. The add ins list is hard for some users to find,
being four clicks from the top.

Anthony

Try...
Add the addin to the 'Add-in Manager' key during install, so Excel
treats it as a member of the Addins collection. Then, if you wish it to
be 'installed' at runtime, add it to the 'Options' key.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

On Jul 5, 2:49*am, GS wrote:
Anthony Berglas formulated on Sunday :





Hello All,

The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.

I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
* HKCU\software\microsoft\office\14.0\excel\Options: OPENn
to the .xlam file that is the add in. *(If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) *The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.

This worked in the beta.

But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.

(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. *100s of events per second
when Excel is just sitting there! *During an add in install it opens
the add in file dozens of times.)

Any ideas as to what happened would be greatly appreciated. *Many
people will have this problem.

A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. *Make the .xlam the top level. * (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) *Then the addin appears in the list, but still needs to be
manually enabled. *The add ins list is hard for some users to find,
being four clicks from the top.

Anthony

Try...
Add the addin to the 'Add-in Manager' key during install, so Excel
treats it as a member of the Addins collection. Then, if you wish it to
be 'installed' at runtime, add it to the 'Options' key.

--
Garry

Free usenet access athttp://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc- Hide quoted text -

- Show quoted text -

Thanks for that. However, in pre XL 2010 the HKEY_CURRENT_USER
\Software\Microsoft\Office\12.0\Excel\Add-in Manager key seems to
simply store the add in name while it is unchecked and thus removed
from the Options:OPENn list. Enabling the add-in seems to move it
back to the Options:OPENn key. It never appears to be in both places
at once.

The value of the Add-in Manager key always seems to be binary 0 (if
present). I have not found any useful documentation.

Have you actually had any success with this on Excel 2010? (Previous
versions work fine.)

Regards,

Anthony

Anthony Berglas laid this down on his screen :
On Jul 5, 2:49*am, GS wrote:
Anthony Berglas formulated on Sunday :





Hello All,

The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.
I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
* HKCU\software\microsoft\office\14.0\excel\Options: OPENn
to the .xlam file that is the add in. *(If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) *The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.

This worked in the beta.

But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.

(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. *100s of events per second
when Excel is just sitting there! *During an add in install it opens
the add in file dozens of times.)

Any ideas as to what happened would be greatly appreciated. *Many
people will have this problem.

A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. *Make the .xlam the top level. * (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) *Then the addin appears in the list, but still needs to be
manually enabled. *The add ins list is hard for some users to find,
being four clicks from the top.

Anthony

Try...
Add the addin to the 'Add-in Manager' key during install, so Excel
treats it as a member of the Addins collection. Then, if you wish it to
be 'installed' at runtime, add it to the 'Options' key.

--
Garry

Free usenet access athttp://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc- Hide quoted text -

- Show quoted text -

Thanks for that. However, in pre XL 2010 the HKEY_CURRENT_USER
\Software\Microsoft\Office\12.0\Excel\Add-in Manager key seems to
simply store the add in name while it is unchecked and thus removed
from the Options:OPENn list. Enabling the add-in seems to move it
back to the Options:OPENn key. It never appears to be in both places
at once.

The value of the Add-in Manager key always seems to be binary 0 (if
present). I have not found any useful documentation.

Have you actually had any success with this on Excel 2010? (Previous
versions work fine.)

Regards,

Anthony

The install script I use writes to both keys. AFAIK, it should be
written to both keys so Excel can handle the management on startup. So,
if it's in the Options key then Excel will note that it needs to be
removed from the Add-in Manager key if there. Thus, it shouldn't (and
will not) appear in both keys at the same time after startup. When you
clear its check mark in the Addins Manager dialog, Excel moves it back
into the Add-in Manager key so it remains a member of the Addins
collection.

Honestly, I don't know if just writing to the Options keys works in any
version because I've always done it the way I was told to by Rob Bovey.
(Incidently, he provided the install script and is what I use whenever
I install addins via the Addins Manager) As you state, it works
correctly when done manually via the Addins Manager dialog, which is
probably because Excel handles it its own way. Installing to both keys
and letting Excel handle internally that seems to be working.

This, however, is not how I do things anymore. I now only install
addins into the Addins collection if I'm providing a utility that's
used with the user's normal instance of Excel.

Because my addins are primarily configured as task-specific apps, I've
gone toward using my own VB6 automated instance of Excel and just
opening the xla[m] in that instance OR use <COMAddin.Connect if the
app is compiled to an ActiveX.dll COMAddin.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

Anthony Berglas has brought this to us :
On Jul 5, 2:49*am, GS wrote:
Anthony Berglas formulated on Sunday :





Hello All,

The way add-ins are installed seems to have changed radically from the
Beta to the final release of Excel 2010.
I have an ordinary VBA Add In, and have for many version of Excel used
a simple installer that sets
* HKCU\software\microsoft\office\14.0\excel\Options: OPENn
to the .xlam file that is the add in. *(If more than one add-in is
installed then the keys are listed as OPEN1, OPEN2...) *The .xlam file
itslef is stored by default in an arbitrary folder, not an addins
folder.

This worked in the beta.

But in the production version, setting this key makes no difference.
I can install the add-in perfectly via the UI, but then a full search
of the registry fails to find any key that points to the add-in.
Moving the add-in files causes Excel to complain, so something is
definitely pointing to them.

(I have tried to use Sysinternals Procmon, but Excel does so much that
it will take time to filter the results. *100s of events per second
when Excel is just sitting there! *During an add in install it opens
the add in file dozens of times.)

Any ideas as to what happened would be greatly appreciated. *Many
people will have this problem.

A work around is to install the files in the %APPDATA%\Microsoft
\AddIns folder. *Make the .xlam the top level. * (In my case I also
have a .xla file for older versions of Excel, but that must *not* be
in the AddIns folder or XL 2010 prefers it over the .xlam and
complains.) *Then the addin appears in the list, but still needs to be
manually enabled. *The add ins list is hard for some users to find,
being four clicks from the top.

Anthony

Try...
Add the addin to the 'Add-in Manager' key during install, so Excel
treats it as a member of the Addins collection. Then, if you wish it to
be 'installed' at runtime, add it to the 'Options' key.

--
Garry

Free usenet access athttp://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc- Hide quoted text -

- Show quoted text -

Thanks for that. However, in pre XL 2010 the HKEY_CURRENT_USER
\Software\Microsoft\Office\12.0\Excel\Add-in Manager key seems to
simply store the add in name while it is unchecked and thus removed
from the Options:OPENn list. Enabling the add-in seems to move it
back to the Options:OPENn key. It never appears to be in both places
at once.

The value of the Add-in Manager key always seems to be binary 0 (if
present). I have not found any useful documentation.

Have you actually had any success with this on Excel 2010? (Previous
versions work fine.)

Regards,

Anthony

Oops! Need to correct my previous post. I looked at an old addin
install script and realize that it only writes the Options key. Sorry
to throw confusion at you!

I can't confirm how it works in MSO 2010 because I don't have it
installed yet. Meanwhile, I've emailed Rob to see if he's encountered
any v2010 behavior anomolies with our script. I'll post back when I
know more.

Again, I apologize for my previous assumptions regarding the Add-in
Manager key.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

According to Rob,
HKCU\Software\Microsoft\Office\14.0\Excel\Options\ Open#
is the correct registry key and works as all previous versions do.

I will confirm that this is the case.

As for my original post regarding
HKCU\Software\Microsoft\Office\14.0\Excel\Add-in Manager, I was reading
my 'uninstall' script instead of the 'install' script. Once again,
sorry for casting any confusion there.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc