[AccessD] Example of Class Module usage needed

Fri Sep 23 18:02:30 CDT 2016

> Do you agree that a module is not a class? 

Short answer, Yes.

Long answer:

JC and I had many discussions about modules, objects, classes, events and Access back in 
the day :)

Suffice it to say that he oversimplified things in his statement.

Modules are just convenient compilable blocks of code.  A Class is closer to a Function that it 
is to a  Module.

Classes are definitions of Objects.
An object is a pre-defined set of data (variables), neatly packaged with a group of 
subroutines (code) which manipulate the data and provide any other functionality you need.
When your application instructs the compiler to create an object, it uses the definitions found 
in the class to do so. It allocates memory for the variables, establishes pointers to the 
subroutines, and makes this new object available to your program.

In other programming environments,  you can intersperse
CLASS...END CLASS  blocks with
FUNCTION...END FUNCTION blocks of code. 

Not so in Access. You can have multiple functions in a single module.

But because of the way the compiler works, each class must be defined in a single separate 
module and it must be designated as a class module 

There is actually a lot of additional code involved in a class definition which the Access 
compiler puts in such as INHERITS and INTERFACE code.  That's why Access classes are 
so limited.  Real OOP allows the developer to define the code for these essential Object 
components.

Bottom line a Class is defined in a Class Module.
Other code is defined in a standard Module.

-- 
Stuart

On 23 Sep 2016 at 11:52, Bill Benson wrote:

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