Building an add-in consists mainly of creating a class module that handles events specific to add-ins and any events you want to specify, along with your support modules and forms. Unless you need to have multiple instances of an add-in running in the same IDE, all class procedures should be declared Private to prevent other routines from inadvertently referencing them.
Once the add-in code is complete, you must compile it as an ActiveX .dll or .exe file, since add-ins must be ActiveX components. For various reasons, it's generally best to create add-ins as ActiveX .dll files.
For more information For a brief comparison of add-ins as .exe and .dll files, see "Compiling Add-Ins" in "How to Build an Add-In." get your feet wet, start by building a very simple add-in that demonstrates an essential component of an add-in — its Class module. How this example works will be explained afterward.
Note The procedure below leads you manually through creation of an add-in. Alternatively, you can simply create an Add-In project, and all of the basic add-in infrastructure is created for you.
To create the AddInProject add-in
This gives you access to the extensibility objects and collections that you need to create add-ins.
Note that there is an icon for an AddIn template. The template includes some of the code necessary for beginning an add-in.
Enter the following code in the new module:
Declare Function WritePrivateProfileString& Lib _
"kernel32" Alias "WritePrivateProfileStringA" _
(ByVal AppName$, ByVal KeyName$, ByVal _
keydefault$, ByVal FileName$)
Sub AddToINI()
Dim rc As Long
rc = WritePrivateProfileString("Add-Ins32", _
"AddInProject.AddInClass", "0", "VBADDIN.INI")
MsgBox _
"Add-in is now entered in VBADDIN.INI file."
End Sub
Alternatively, you can use the Add-In designer to create a reference to your add-in. For detailed instructions about how to do this, see "Referencing Add-Ins" in Chapter 4, "Connecting and Exposing Add-Ins".
Implements IDTExtensibility
This adds a reference to the IDTExtensibility object to your project.
Notice that four new events appear in the Procedure box: OnConnection, OnDisconnection, OnStartupComplete, and OnAddInsUpdate.
While you can enter the procedure syntax manually, it's strongly recommended that you click the event name in the box to add the procedures to the Class module to ensure that all names and arguments are entered correctly. Plus, it's faster!
All four of these event procedures must be present in your Class module for add-ins to work correctly. Also, if one or more of the event procedures has no code in it, it will be removed upon compilation, so it's important that you add at least a comment to each of the four events to ensure that they remain in the Class module when you compile.
Private Sub IDTExtensibility_OnConnection(ByVal _
VBInst As Object, ByVal ConnectMode As _
VBIDE.vbext_ConnectMode, ByVal AddInInst As _
VBIDE.AddIn, custom() As Variant)
MsgBox "Add-in is now connected"
End Sub
Private Sub IDTExtensibility_OnDisconnection(ByVal _
RemoveMode As VBIDE.vbext_DisconnectMode, _
Custom () as Variant)
MsgBox "Add-in is now disconnected"
End Sub
Private Sub IDTExtensibility_OnStartupComplete _
(custom() As Variant)
' Comment to prevent procedure from being
' deleted on compilation.
End Sub
Private Sub IDTExtensibility_OnAddInsUpdate _
(custom() As Variant)
' Comment to prevent procedure from being
' deleted on compilation.
End Sub
File | File name | Extension |
Basic module | AddIn | .bas |
Class module | AddInClass | .cls |
Project | AddInProject | .vbp |
To test the AddInProject add-in
This will register the add-in in the system registry.
AddToINI
and press RETURN. You get a message box that says "Add-in is now entered in VBADDIN.INI file."At this point, you should get the following dialog box:
You should get the following dialog box:
The purpose of this add-in is to demonstrate the components and behavior of an essential component of an add-in — its Class module. Let's go through each of the previous steps and discuss what it did, and more importantly, how and why it was done the way it was.
This brings up an important point: When you distribute an add-in to other users, either you or they must run this function (or use some alternative method) on their machines to update the Vbaddin.ini file before they'll be able to use your add-in. If you don't do this, Visual Basic won't know that the add-in is available, and the add-in won't appear in the list of add-ins in the Add-In Manager.
You can put such a procedure in a basic module (as was done here) and instruct the user to run the function, but a more elegant solution is to do it for the user in a setup program that you supply to install the add-in.
Alternatively, you can use the Add-In designer to create a reference to your add-in. For detailed instructions about how to do this, see "Referencing Add-Ins" in Chapter 4, "Connecting and Exposing Add-Ins".
Although the main Class module is useful, it's best not to put all of the code in it, unless it's brief. You can put other code in basic modules or other Class modules and call the procedures from the main Class module. Just follow your normal procedural programming guidelines.