When I login as the administrator on my NT Workstation machine, I see a ton of Add-Ins in the Add-In manager. When I log in as myself, I get just a couple.
Any thought?
[sig]<p> Tarek<br><a href= > </a><br>The more I learn, the more I need to learn![/sig]
Add-Ins are specific to the user who installed VB in the first place, the DLL's and OCX's that make up the Add-Ins are only registered in the registry for that user. This is, in reality, a bug in VB in my opinion (and in the opinions of our admin chaps) and the only way around it is to register the DLL's and OCX's for each user, using Regsvr32.
What we do where I work is have a script which registers all the most common Add-Ins, which you can then run if you ever lose your Add-Ins if, for instance, your Domain Controller goes down and you have to create a new profile.
Here's the script we use, obviously you'll probably want to change the various drive letters and directories and you possibly won't want all the libraries involved, but if you save this as a .cmd file and run it, it'll register all the standard Add-Ins that come with VB Enterprise Edition. If you try to register a component that doesn't exist, the script will just carry on anyway without erroring.
cut and paste all of the text after and including the @REM into a text editor (notepad for instance) and save the file as AddInSetup.cmd. You can pretty much call it anything you like, but the .cmd extension is important, as this is what denotes it as being a command script, which is very much like a batch file. Then, from the command prompt, type the name of the script you just saved (AddInSetup if you called it that) and press return. The script will then run and register all the relevent DLL's and OCX's. Alternatively, from explorer, you can double click on the script and run it that way - it'll open its own DOS window and close it upon completion.
Can you actually register an EXE? The API Viewer still doesn't show up in the Add-In Manager!
[sig]<p> Tarek<br><a href= > </a><br>The more I learn, the more I need to learn![/sig]
You can register some .exe applications, as it is possible to write an executable which also behaves as an ActiveX Server, which means they can be treated the same as registerable .dll libraries. They can also be used as stand alone executables, the overhead is that communication between an ActiveX exe instantiated as an object and the instantiating program is far slower than that between an ActiveX dll and the instantiating program. The reason for this is that a dll and its calling program share the same address space, so the data transfer between them is very efficient, even allowing for the overheads COM (the underlying standard that handles object interactivety) adds for ActiveX dll's. An ActiveX exe, however, even when instantiated as an object, is a seperate program altogether, so has its own process / address space in memory. COM must set up a communication system called marshelling to transfer data across the process boundary between the ActiveX object and the calling program, for which the overhead of doing so is relatively high.
Fascinating, but not particularly vital to know...
The API viewer should be registered by the script I gave you, you might want to check that the relative component is present in your system. The one you're looking for is, in fact, the .exe you pointed out. It should appear in the Add In Manager list as VB6 API Viewer.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.