Greg Lovern brought next idea :
On May 25, 5:16 pm, GS wrote:
Any software 'Setup' utility will do what I'm talking about. You have
to provide the script yourself.
It sounds like we're talking about the same thing. I used an off-the-
shelf installer and added script to register the add-in with the
installed versions of Excel.
I use Wise and write my own scripts. What do you use?
I thought you said in this group that Rob Bovey wrote the script you
use:
"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)"
Yes, Rob did provide me with the original 'Registry key' script. (He
didn't say he wrote it, only that it was what he uses) I used that
script for installing addins in the user's default instance of Excel
(as via the Addins dialog). My addins use their own automated instance
of Excel and so I had to rewrite my installer script accordingly. I do,
however, still use the 'Registry key' script Rob provided me with for
utility addins for installing into a client default instance of Excel.
In any event, the script has to be written since installers don't (as
you state) provide such scripts 'out-of-the-box'. Also, I use Wise for
installing stand-alone Windows apps as well.
Note that with the release of Vista/Win7, all scripts were re-written
to establish access permissions for my projects (XLAs or VB6 EXEs) to
be able to write to their respective folders without being hampered by
UAC. As a result, the only part of the scripts provided by Rob that
remain is the Registry key processing. The addins that use their own
automated instance of Excel don't require the Registry settings because
automated instances don't include installed addins, and I don't want
them 'installed' as addins in the user's default instance. Automated
instances just require the XLA be opened as any workbook would be.
I'm still using VB6 Package and Deploy. Need to move on when time
allows.
Yeah, for sure1 There's a lot of interest in Inno Setup and I think
there's free version of it available.
Off the shelf, it has nothing in it for registering Excel add-ins, so
I wrote all that myself.
Yep, that's why I went with Wise; it's what Rob was using and he
offered me his script without me asking for it. I didn't have VB6 at
the time but I did have the Developer version of MSO2000, which shipped
with the
VB P&D wizard. Obviously, I couldn't use his Wise script with
P&D so I bought the Wise package.
This covers only half the job. You're installer script should also
delete any entry that may exist in the Add-in Manager key in the event
the addin is not listed in the Options key.
How would that factor into the problem?
See below...
Excel writes to that key when the user unchecks an add-in from the Add-
ins dialog. I don't understand how that key could have caused the
original problem unless Excel somehow wrote the VirtualStore path to
the Add-in Manager key. But VBA reported it (per thisworkbook.path) to
be in the installed path, not the VirtualStore path.
I tested just now to see whether Excel 2002 VBA would report the
installed path when the registry entry actually pointed to the
VirtualStore path. I unchecked the add-in from the add-in dialog, so
that Excel removed the add-in from the Options key and added it to the
Add-in Manager key, then went into the registry and changed the path
in the Add-in Manager key from the installed path to the VirtualStore
path, then went back into Excel and checked the add-in in the Add-Ins
dialog. Then I went into the VB editor and checked thisworkbook.path.
It reported the VirtualStore path -- the path I had just put in the
registry -- not the installed path. So, it looks like the fact that
VBA reported the installed path during my original tests shows that
the Add-in Manager key had nothing to do with the VirtualStore path
problem.
Clearly Excel along with its registry entries thought the add-in was
in the installed path, while Windows 7 was redirecting to the
VirtualStore path.
Win7 didn't redirect anything. You just stated that you changed the
setting from installed path to VirtualStore and when you checked in VBE
it reported what you had changed it to. Why would it report something
other that that. The entry from the Add-in Manager key that you changed
to VirtualStore was moved to the Options key when you went back and
checked it in the Addins dialog. Seems to be working correctly to me,
unless I'm misunderstanding what you're saying here.
I'm going to try to explain what you just discovered in terms that also
may help you understand why I mentioned that Excel should not be
running when you run your installer.
There's 2 scenario possibilities at install time:
1. Addin is installed and so is listed in Options key
2. Addin is not installed and so is listed in Add-in Manager key
It can't be listed in both places at the same time, as I expect you're
already aware of. If you write to Options during install while the
addin is listed in Add-in Manager, you must remove it from Add-in
Manager. Since your script doesn't know where it's listed, it's safe to
assume that you should enter it in the next available Options\OPEN key,
but make sure you also remove it from Add-in Manager in case it happens
to be listed there if not 'installed' at the time your installer runs.
Now here's the kicker; there's a separate set of keys for each version
of Excel that's installed on the target machine. That means each
version must be in its own folder under Program Files\Microsoft
Office\. That precludes that your installer must loop through to find
every installed version, then update both Registry keys for each
version. Doing this causes all installed verions to use the same
addin.xla file.
--
Garry
Free usenet access at
http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc