[AccessD] Example of Class Module usage needed

[Bill Benson]

Do you agree that a module is not a class? Isn't it a class (member) of
type vbComponent?
On Sep 22, 2016 7:40 PM, "Stuart McLachlan" <stuart at lexacorp.com.pg> wrote:

> 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
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>