[AccessD] Classes and Events – Using a library

An access library consists of an access container that contains code which will be used in more than 
one Access application.  Just as in the case with classes, the objective is to have a single place 
to go to store, find and maintain code that is useful in more than one specific place, in this case 
in more than one application.

My rule of thumb is that if the code is specific to an application, then that code belongs in that 
application.  If the code can be used in more than one application, then that code belongs in a 
library.

Libraries in Access are traditionally named with an MDA or MDE extension, however in fact that is 
not a requirement.  Any Access container can in fact have any extension, or even no extension at all 
and it will still function perfectly.  Access can open an FE regardless of extension, can link to 
tables in a BE regardless of extension, and can reference code in a library regardless of extension.

The extension is useful however when trying to reference the library, since the reference dialog 
will automatically add a filter of .mda and .mde to the file find dialog and when those extensions 
are selected in the dialog, only objects with those extensions will show in that dialog.  Thus if 
you do happen to use the MDE/MDA extensions it will make the library easy to find in a cluttered 
directory.

A library is like any other MDB in that locks are created to work in it etc. so it is often best to 
copy the library to a location local to the user’s workstation, then reference the library at that 
local location.  I usually copy the FE to the local workstation as well, so I just place the library 
in the same directory that I place the FE.

If a reference is broken, Access will search a specific set of paths, beginning with the location of 
the FE.  This being the case, the library will be immediately found and the reference repaired by 
Access automatically.  What this means to you is that if you place the library in the same directory 
as the FE, the reference does not matter, as long as a reference exists.

As we know, code has scope.  A call to a function will first be searched for in the current module 
of the calling code.  If not found, the function will be searched for in other modules in the 
current DB container.  If still not found, the function will be searched for in the referenced 
objects, in the order of the references, in other words from the top down in the references dialog.

The implication here is that you can have the same class name, function, constant or variable in 
several different places, and the first place it is found is the copy that will be used.  This can 
cause extremely difficult to track problems as you might expect.  Often times I develop code in the 
FE container, and when I get it debugged (assuming that it is not FE specific) I will then move it 
to the library.  If I am not careful to cut the code and paste it into the library, I can end up 
with the same code in the FE and the library.  If I then go to the library to make changes, my FE 
will not see those changes since the code in the FE is found first, but I made the changes in the 
library.  If I make changes in the FE but use the library in several different Fes, the code may 
work differently in the other Fes, because they do not have a local copy of the code.  It is 
important to keep this “first found” rule in mind as you develop your code.

Many people become familiar with libraries before they discover classes.  Often developers discover 
libraries, and start moving code from their FE to the library, which is the correct thing to do. 
Once they discover classes, they start designing classes in the FE, then when they move the class to 
the library the classes cannot be seen outside of the Library.

The problem is that classes are intentionally not exposed outside of the library.  I have never red 
a cogent explanation of why Microsoft made this decision, but it is a simple fact that without 
taking special steps, classes cannot be seen outside of the Access container that they exist in.

It is however possible to cause them to be exposed outside of the database container they are in. 
There are two ways to do this.  The first is to design a function wrapper, and return an object type 
pointer to the wrapped object.  The problem with this approach is that you lose intellisense.  In 
other words, an object reference does not provide you with the properties and methods of the object 
that it represents.  It is just a naked pointer to “something”.

The second method is an “officially undocumented” trick which allows you to edit the class 
properties that keep it unexposed, and in the process expose the class from the outside of the 
Access database container or library.  The process consists of exporting each class that you wish to 
expose to a text file.  Doing so will expose a set of properties in the header of the class which 
are normally invisible and cannot be manipulated.  Because they are exposed in the text file, you 
can toggle two of the properties, save the file to disk again with these properties modified, then 
import the class files back in to the database.  Once you have done this, the class object can be 
seen from outside of the library just like any public variable or function can.   We will be using 
this second method.

In this lecture we have discussed using a library to hold code that is useful to more than a single 
application.  We have discussed a few details of referencing the library modules and how copying 
them to the local workstation is often a good strategy.  We have learned a little about code scope 
and discovered that moving code to a library can cause issues if you have function or variable names 
defined the same in the FE and the library.  Finally we discussed a major issue with using classes 
from outside of the library and a couple of strategies for dealing with the problem.

In the next lecture we will take our demo database and turn it into a library and a FE.  We will 
expose the classes that we need to make public, and we will then reference our new library from our 
new FE.  We will then demonstrate using the classes inside of the library.

-- 
John W. Colby
www.ColbyConsulting.com