[AccessD] Example of Class Module usage needed

[John Colby]

Holy cannoli man, I wrote that?  :)


On 9/23/2016 11:52 AM, 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
>>

-- 
John W. Colby