[AccessD] Classes and Events

Drew Wutka DWUTKA at Marlow.com
Mon Feb 9 12:40:12 CST 2009


To clarify (if you don't mind JC), a class module can only raise it's
OWN events.  IE, if you have 20 command buttons, clicking a command
button will raise THAT command buttons 'OnClick' event.  Now, from code,
you can CALL 'MyCommandButton_OnClick' which will run the code you have
on your form (which is handling the OnClick event of that command
button, but it's not actually raising the event.  If other class modules
have that command buttons events sunk into them, only clicking the
button (having the command button raise it's own event) will trigger
them all. 

Now, to be even more specific, class modules usually have a way to
trigger their events programmatically.  For instance, the OnOpen event
of a form, can be triggered by programmatically opening that form.  

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, February 09, 2009 11:51 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Classes and Events

Philippe,

Understand that only a combo can RAISE a combo event, only a command
button can RAISE a command 
button event.  To RAISE an event means that an OBJECT "broadcasts" an
event that it knows how to RAISE.

You can SINK the combo event in a class, IF you have dimensioned a combo
variable "WithEvents", and 
IF you have captured a pointer to said combo in the class.

Stay tuned, you shall see how it is done.

John W. Colby
www.ColbyConsulting.com


philippe pons wrote:
> Hop, this is interesting:
>  A regular module cannot RAISE an event, but a class can
> 
> So following a previous post, a question arises:
> How would you raise a combo box event with a class?
> 
> TIA,
> 
> Philippe
> 
> 2009/2/9 jwcolby <jwcolby at colbyconsulting.com>
> 
>> 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
>> --
>> 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
The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.





More information about the AccessD mailing list