[AccessD] Classes and Events

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
>