[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
>>