Running too many add-ins?

[greggbeck2000]

I need information about add-ins. I plan to create a large number of
custom add-ins designed specifically for users within my company. My
concern is that some users might install and enable many of them,
causing machine slow down. They might even neglect to disable those
they don't use anymore.

What are the limitations of add-ins, as far as volume that can be
installed and used? How much of an impact on memory and resources does
running many add-ins have?

Any suggestions on how to help users manage their add-ins, or how to
create/distribute them for less negative impact?

If you have pointers to more detailed information I can use for
research on this subject, I'll take them.

Thank you.

v2002

 

[Steve Rindsberg]

I need information about add-ins. I plan to create a large number of
custom add-ins designed specifically for users within my company. My
concern is that some users might install and enable many of them,
causing machine slow down. They might even neglect to disable those
they don't use anymore.

What are the limitations of add-ins, as far as volume that can be
installed and used? How much of an impact on memory and resources does
running many add-ins have?

How many did you have in mind? I typically have ten or more loaded all the
time and don't notice any real tug on system resources; PowerPoint starts up a
bit slower, the more addins are loaded at startup. For the most part, the
addin code isn't really *doing* anything until it's invoked.

Any suggestions on how to help users manage their add-ins, or how to
create/distribute them for less negative impact?

You might be able to work out some sort of load-on-demand scheme to speed
startup, and it's certainly possible to, say, enumerate the addins in a folder
and give the user e.g. a list box and let them choose which to load and unload
at need. You might also be able to set the addins NOT to load automatically
and have them load only as called upon.

But unless you're loading huge numbers of addins, I don't expect you really
need any elaborate schemes; and if you *are* loading that many add-ins ...
hows come? ;-)

 

[Gregg]

I'm not sure of the number of add-ins, but I'm certain it will grow
over time. I plan to offer more than any a reasonable user would want
to load at once. But the level of reasoning with some of my users gives
rise to my concern. ;-) Also, many add-ins just might apply to a user,
justifying their reasons for loading a lot. I want to be prepared for
the eventual challenge, but so far your feedback is encouraging.

The custom-built add-ins would address specific tasks within our
company. They will be designed from an ongoing tasks survey. My idea is
to have add-ins offered on our intranet in areas of task, subject,
department, job title, etc., where they could DL them onto thier
machines. Some add-ins would offer multiple related features and others
a single feature. Some would be simple, others complex. But, I envision
some user needlessly downloading the entire collection out of
confusion. There again is my concern that it will jack up PowerPoint.

Of course I will start with a small sample as a test and take it one
step at a time from there. But one thought that hits me is how to DL
the add-in directly into the specific folder where it can then be
enabled in PPT? I'm thinking that would have to be an EXE file to do
that? Is there a way to have it DL and be enabled in PPT on the users
machine without them having to do any configuring?

Thanks for your time and thoughts.

 

[Steve Rindsberg]

The custom-built add-ins would address specific tasks within our
company. They will be designed from an ongoing tasks survey. My idea is
to have add-ins offered on our intranet in areas of task, subject,
department, job title, etc., where they could DL them onto thier
machines. Some add-ins would offer multiple related features and others
a single feature. Some would be simple, others complex. But, I envision
some user needlessly downloading the entire collection out of
confusion. There again is my concern that it will jack up PowerPoint.

Of course I will start with a small sample as a test and take it one
step at a time from there. But one thought that hits me is how to DL
the add-in directly into the specific folder where it can then be
enabled in PPT? I'm thinking that would have to be an EXE file to do
that? Is there a way to have it DL and be enabled in PPT on the users
machine without them having to do any configuring?

If the addins are available on a network share, for example, an uber-addin
could use FileCopy to move the PPA file to the user's local hard drive and load
it on the fly. By doing this you could also do things like check how many
addins are loaded ( Application.AddIns.Count ) and tell the user to unload some
if need be.

Downloading from the internet would be more complex but once the file's on the
local hdd the logic's the same.

I'd be inclined to put more decision-making and functionality into fewer addins
than to make tons of tiny addins on the theory that each addin adds an amount
of inevitable overhead. That's instinct more than specific knowledge talking,
mind.

 

[Gregg]

I think, too, "packaging" the smaller add-ins together would be best.
I'll have to see what I can use to code the DL from our intranet when
the user clicks the link.

I'll let you know how it goes and what I find when I start this. Thanks
for your time.

 

[Steve Rindsberg]

I think, too, "packaging" the smaller add-ins together would be best.
I'll have to see what I can use to code the DL from our intranet when
the user clicks the link.

If they can access it as a mapped or UNC path, it's a piece of cake:

FileCopy \\servername\sharename\path\file.ext, c:\localfolder\localname.exe

Unfortunately, that won't work with URL paths.

 

[Gregg]

Ok, I understand the code you wrote, but are you saying that would be
the reference string for the link? I've never written one like that. Or
are you saying that command line would go somewhere else?

I use UNC's, and prefer them, so that won't be a problem for the
source, but the destination path might involve a variable. I have to
decide what's best to copy to - a hard drive folder (no variable) or a
profiled folder (variable). The benny of the latter is they retain the
addins even though they move to a new machine.

Here's an example of a profiled path:
C:\WINNT\Profiles\ThisIsMyName\Application Data\Microsoft\AddIns

You can see the variable "ThisIsMyName". It seems going this route
might require a bit of server side script to capture their profile ID
and concatenate the destination path.

BUT... to slam it into a local folder is awfully tempting and would
reduce work and red tape. So far I'm leaning for this simpler solution.

So, once the add-in is DL'ed and setting in a local folder, would the
user still have to "add" it through Tools|Add-Ins, or is there a trick
to make that happen?

Hey, Steve, mucho thanks for your time in helping me sort out my
initial thoughts on this. It's been a great help.

 

[Steve Rindsberg]

Ok, I understand the code you wrote, but are you saying that would be
the reference string for the link?

No, just for copying the file to a local folder from a UNC or mapped drive ...
it doesn't work for files accessed via HTTP or FTP.

I've never written one like that. Or

are you saying that command line would go somewhere else?

I use UNC's, and prefer them, so that won't be a problem for the
source, but the destination path might involve a variable. I have to
decide what's best to copy to - a hard drive folder (no variable) or a
profiled folder (variable). The benny of the latter is they retain the
addins even though they move to a new machine.

Here's an example of a profiled path:
C:\WINNT\Profiles\ThisIsMyName\Application Data\Microsoft\AddIns

You can see the variable "ThisIsMyName". It seems going this route
might require a bit of server side script to capture their profile ID
and concatenate the destination path.

BUT... to slam it into a local folder is awfully tempting and would
reduce work and red tape. So far I'm leaning for this simpler solution.

Consider that you can locate the path where PPT's installed and copy relative
to that ( Application.Fullpath ) or your "master" addin can figure out where it
is and you can install to the same path or to a relative path. That might be
the best bet. Set a constant in the addin to the addin's name and:

Application.AddIns(MyName).Path

give you the path to the addin.

So, once the add-in is DL'ed and setting in a local folder, would the
user still have to "add" it through Tools|Add-Ins, or is there a trick
to make that happen?

You can load addins programmatically:

Application.AddIns.Add ("c:\path\to\someaddin.ppa")
AddIns("someaddin").Loaded = True

Hey, Steve, mucho thanks for your time in helping me sort out my
initial thoughts on this. It's been a great help.

My pleaasure.

 

[Glen Millar]

I think, too, "packaging" the smaller add-ins together would be best.

Smart move! It is called "User Centred Design" <g>.

 

[Steve Rindsberg]

Smart move! It is called "User Centred Design" <g>.

Gee, and here I was thinking of it as a kind of "Programmer Sanity Centered
Design" feature.

 

[Gregg]

Yeah, with my work load, I'm using as much "Self-Centered" design as I
can.