[AccessD] Classes and Events

A QUICK introduction to classes and events.


CLASSES:

* The Code Behind Forms module in a form is a class module.
* A class is a module, but a module is not a class.
* A class has properties and behaviors that a module does not.
* A class is actually instantiated when a set statement is executed.  In other words, an INSTANCE of 
the class is loaded into memory, and stays in memory until it is specifically unloaded.
* Like a module, a class can contain data (variables) and code.  However the variables in a module 
can only contain ONE value at a time.
* A class can be loaded into memory as many times as you want (limited only by the size of your 
memory) and EACH INSTANCE of a class can contain its own value in its variables.
* All instances of a class SHARE code, but do not share variables.  In other words, the code is only 
loaded into memory one time, but the variables are loaded once per class instance loaded.
* The class (and every object, including forms and controls) unloads from memory when the last 
variable holding a pointer to the object is set to nothing.
*A class has two built-in Events that fire, one as a class instance loads (Class_Initialize), and 
the other as the class instance unloads (Class_Terminate).

Think of a class as a place to store information and code about some thing in the real world. 
Perhaps you have a clsPerson.  That class has a bunch of variables called FirstName, LastName, SSN, 
ColorHair, ColorEyes, Gender, Birthdate etc.  Load an INSTANCE of that class and fill in the data 
about John Colby, load another instance and fill in the data about Mary Colby etc.  You might then 
have a piece of code that takes the birthdate and calculates the current age from that.  The data 
and the code are all stored together in the class.

EVENTS:

Events can be thought of kind of like a radio transmission.  The radio station transmits a signal, 
but they have no idea whether anyone is listening.  In the case of events, this is called “Raising 
(or sourcing) and event”.

If someone is listening to that radio signal, then the person listening can do whatever they want 
with the signal they are receiving.  They can do nothing at all, they can use it as a signal to 
launch an attack on an enemy, they can enjoy music, they can…  The important thing to understand 
here is that what the listener does is up to the listener.

In the case of events, receiving the signal is called “sinking” the event.

Notice that the person broadcasting the signal doesn’t know or care whether anyone is listening, nor 
do they know or care what the listener (if they even exist) does with the signal.

When you open a form, the form is constantly raising events.  It raises OnOpen, OnClose, OnCurrent, 
BeforeUpdate, AfterUpdate, MouseMove etc etc.  The events are raised whether or not anyone is 
listening.  The form neither knows nor cares whether anyone is listening to (sinking) those events, 
it is simply raising these events so that if anyone is listening to (sinking) the events, they can 
do whatever they want when the events fire.

When you place a control on the form, the control raises events under certain circumstances.  When 
the control gets the focus it raises an OnFocus event, when it loses the focus it raises a LostFocus 
event, it raises a BeforeUpdate, AfterUpdate etc.  Of course these events depend on what the user 
does, in other words they don’t happen unless the user manipulates the control in the correct 
manner, enters data for example.  But notice that while the control always raises the event, it 
neither knows nor cares whether anyone is listening, nor does it know or care what the listener does 
with the event if anyone is listening (sinking the event).

This is a critical thing to understand, that the object raising an event does not know nor care 
about the listener, nor what the listener does.   The reason that this is critical is because it 
allows you to design an interface between objects which is totally asynchronous or disconnected. 
Have you ever built a subform and referenced a control on the parent form?  Have you ever tried to 
open that subform by itself?  It complains that it cannot find the control on the parent.  The 
subform is has a “connected” interface to the parent, without the parent it cannot do its thing 
correctly.  The event “Raise/Sink” interface eliminates that dependence.  The object raising the 
event does not depend on having a receiver of the event in order to function correctly.  The 
receiver of events does not depend on the broadcaster existing in order to function, although of 
course it cannot do whatever it would do with the events if they are not being broadcast.  But each 
side can be loaded and code can execute without the other side being loaded, without compile errors etc.

The last thing to know is that regular modules cannot sink events, but a class can.  A regular 
module cannot RAISE an event, but a class can.  Classes are modules, but modules are not classes.

This is just a teaser to see if anyone is interested.

If yes continue lecture else end if.

-- 
John W. Colby
www.ColbyConsulting.com