[AccessD] Classes and Events

 > To clarify (if you don't mind JC)

Not at all Drew.  This stuff is just different enough that having things said in a slightly 
different way may be just what is needed for it to "click" (pun intended).

To expound a bit further on Drew's example, if you have 20 command buttons, and if each command 
button is going to need the same code, then you would instantiate the command button class 20 times, 
and each instance would handle ONE COMMAND button.  The button's Click event would be sunk right 
inside of the class, the code to run would be right inside of the class etc.

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> 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
>>>