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.