[AccessD] Example of Class Module usage needed

[Stuart McLachlan]

John Colby is the Class expert.  Following is the start of a long series of posts he made back 
in early 2009.  If he still has the full series, he may post them.  If not, I've still got them 
archived :)

"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."





On 22 Sep 2016 at 16:22, ewaldt at gdls.com wrote:

> I've been automating Access and Excel for years, but never got
> involved in creating class modules (except the ones behind forms and
> reports, of course). I'm now in the process of converting one of my
> Excel projects over to using a class module, and I can see where it's
> going to be useful (very quick, too). In this case, the class
> basically a more capable, more flexible array, with some methods built
> in. I'm having trouble envisioning why they would be needed in Access,
> though. Obviously they ARE needed, but I don't see it. Other than the
> built in methods, it seems like tables and arrays would handle
> everything. Would anyone like to offer an example of how you would use
> them? 
> 
> Thanks in advance for any help (and patience).
> 
> Tom Ewald
> Mass Properties
> General Dynamics Land Systems
> 
> ----------------------------------------------------------------------
> This is an e-mail from General Dynamics Land Systems. It is for the
> intended recipient only and may contain confidential and privileged
> information.  No one else may read, print, store, copy, forward or act
> in reliance on it or its attachments.  If you are not the intended
> recipient, please return this message to the sender and delete the
> message and any attachments from your computer. Your cooperation is
> appreciated. && -- AccessD mailing list AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd Website:
> http://www.databaseadvisors.com
>