You know this (nearly but not quite fit-for-purpose) References dialog provided by the VBE ...
... that is used to add or update references from your VBA Project to other VBA Projects or to Type Libraries (Type Libraries are explained further in the What's a Type Library and what do they do for VBA? section, below). I got fed-up with having to use it and so created my own version within VBE_Extras which looks like this ...
Install VBE_Extras and it is available by right-clicking on the VBA Project name within the Project window, selecting 'Extras' then 'Update "Project References"'.
Why bother using this rather than the VBE's equivalent dialog?
You can search/filter by name, filename or GUID for specific Type Libraries and VBA Projects (in the screenshot above, the filter applied is for all VBA Projects and Type Libraries with "script" in their name)
View both Type Libraries and Projects or just one-or-the-other
Retains a list of recently added Type Libraries so that you can quickly re-add them (to the same or to a different Project)
Displays the Version and, optionally, the Flags, Language ID, Resource ID and GUID for each Type Library
Displays a Type Libraries 'program' name (via right-clicking on the Type Library in either the 'Current References' or 'Available References' list)
Why is knowing the 'program' name useful?
When using early binding, the 'program' name is the name you use in VBA code to refer to the library which, when followed by a '.', shows the names of all of the available 'types' that the library provides in the VBE's Intellisense window.
For example, the 'program' name for the 'Microsoft Scripting Runtime' is 'Scripting' … if you add 'Microsoft Scripting Runtime' as a reference and then in VBA code type 'Scripting' followed by a '.', you will see the names of the available 'types' (they are actually classes ... more on this below) that the 'Microsoft Scripting Runtime' library provides.
While the 'program' name is often similar to the library name or filename, it does not have to be - for example, if you didn't know from other sources, working out that the 'program' name for the 'Windows Script Host Object Model' library (filename 'wshom.ocx') is 'IWshRuntimeLibrary' could take you some time (and the VBE provides no simple way to find it … other than trawling through thousands of entries in the Intellisense window).
What's a Type Library and what do they do for VBA?
Microsoft's definition of a Type Library is "a binary file that stores information about a COM or DCOM object's properties and methods in a form that is accessible to other applications at runtime. Using a type library, an application or browser can determine which interfaces an object supports, and invoke an object's interface methods. This can occur even if the object and client applications were written in different programming languages".
The following is my attempt to try and clarify that ... but this is a brief overview and only covers the key aspects of Type Libraries from the point-of-view of VBA code.
A Type Library is a file that contains one or more 'Types'. Types are Classes, Modules and Enumerations (there are other types of Type but they are either not available to VBA or, in the case of Interfaces, they used by VBA 'internally' but are invisible to the programmer) and they, in turn, contain Functions and Variables.
Now the naming gets a bit odd if you are used to VBA.
Functions in a Type Library can be equivalent to VBA Functions (i.e. they return a value), they can be Subs (in Type Library-speak, they return 'void') and they can be Properties (Get, Let and Set ... same as VBA).
Variables in a Type Library can be equivalent to VBA variables (i.e. they hold a value that can be updated) or they can be constants (like a Const in VBA) or they can be an Enumeration (i.e. Enum) member (same as VBA)
... a variable that is constant?! Only Microsoft.
Having added a reference to a Type Library, you can then use its Classes, Modules, Enumerations, Functions and Variables from VBA.
In the screenshot above (in the Why is knowing the 'program' name useful? section), I'm about to add the Class 'FileSystemObject' from within the 'Microsoft Scripting Runtime' Type Library (which has a 'program' name of 'Scripting') as the definition of the 'fso' variable.
Once I've done that, if I type 'fso.' then as soon as I type the '.' (see screenshot below) I can see the names of all of the Functions and Variables within the FileSystemObject Class (in this case, using the naming convention of Type Libraries they are all Functions ... using a VBA naming convention they are all Functions except 'Drives' which is a Property ... this fact is given away by the icon).
So Type Libraries massively extend the capabilities of VBA by tapping-into functionality provided by code in other files.
Let's go on another level ... because the Functions and Variables of VBA itself are provided by a Type Library ... in this case the 'Visual Basic for Applications' Type Library (that every VBA Project always has as a reference to ... it is the first reference and cannot be removed) which has a 'program' name of 'VBA'. If you type 'VBA.' then you will see the Types, Functions and Variables of VBA itself (the icon is the only way of telling which-is-which from within the small Intellisense popup). It's confusing and unhelpful that both the Types and the children of the Types (i.e. the Functions and Variables) are all displayed at once ... again, only Microsoft! However, if you select one of the Modules (which are kind-of 'static' equivalents of the Classes that the Microsoft Scripting Runtime provides) such as 'FileSystem' and then type another '.' you will see only the Functions (FileSystem has no Variables) of the FileSystem Module:
You can do likewise for the 'Microsoft Excel 16.0 Object Library' Type Library which has a program name of 'Excel' (and the same for the Type Libraries of the other Office applications which have the program names you would expect) which provides the Excel 'object model'. If you add this code
Then you are actually just omitting the program name of the Type Library which is 'Excel'
And now you can see that you have declared wkb to be an instance of the Workbook Class within the 'Microsoft Excel 16.0 Object Library' Type Library (program name 'Excel') and if you then go on to type 'wkb.' the Intellisense popup will show you the Functions and Variables available within the Workbook Class
To read more about Type Libraries, see Contents of a Type Library and to learn how to explore the contents of Type Libraries see my Type Library explorer post.
And one last thing: the 'Res ID' (Resource ID). The 'default' file type for a Type Library is a .tlb file. Such a file contains only 1 Type Library. However, Type Libraries can be contained in other types of file such as .dll or .exe files and these files can contain multiple 'resources' (not only Type Libraries). The Resource ID, then, indicates which resource within the file the Type Library is. If the Resource ID is omitted, it has a default value of 1. The Resource ID is appended to the file path following a backslash.