[AccessD] Primer on WithEvents and RaiseEvent

Charlotte Foust cfoust at infostatsystems.com
Thu Nov 20 10:24:58 CST 2003


I think you've hit on it, John.  I had the same experience of studying
Shamil's stuff and suddenly understanding it.  Unfortunately, I still
have difficulty explaining it to anyone else.

Charlotte Foust

-----Original Message-----
From: John W. Colby [mailto:jcolby at colbyconsulting.com] 
Sent: Thursday, November 20, 2003 6:49 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Primer on WithEvents and RaiseEvent


Thank you, thank you, (takes a deep bow).  <grin>

As you can see it was actually a chapter in a book.  I had some pretty
nitpicky tech editors going at it and in the end, one of them still just
didn't understand the whole thing.  That really isn't surprising
however, it took me three passes at Shamil's stuff on his web site
before I finally "got it".  Now I look back and scratch my head
wondering why - the basic stuff is just dead simple.

I really think it's the concept of an event being radiated and ANY class
can listen if the programmer knows how to set it up that threw me.  We
all come from the idea that a control BELONGS to a form and only the
form can hear it's events, and nothing in Access ever tells us
otherwise.  Then along comes withevents which tells us that every event
generated by any object can be picked up in any class anywhere (on the
same machine), whether in a form, a different form, or just a class
loaded by some piece of code somewhere. If the listener has dimmed an
instance of that KIND of object (lets say a
combo) and received a pointer to the exact object (combo) that it wants
to listen to, then it can receive control when that object's events
fire.

I built a class (as mentioned in this chapter) for a real client, an
insurance company. They had a business rule that they modeled with a set
of 5 check boxes.  These check boxes tied directly to 5 Boolean fields
in a table.  The check boxes were inter-related, one meant the claim was
a maternity claim, an accident, an illness, was auto related or was
workers comp.

It sounds weird I know but that's one of the ways they sorted and looked
at their claims.  So the SET of checkboxes had to be handled as an
entity, they interrelated.  An accident was NOT an illness.  A maternity
claim WAS an illness and was NOT an accident.  Auto related WAS an
accident and NOT an illness.  And then there were rules as to which of
the above could be workers comp.

In order to prevent data entry errors, I needed to do checking as they
clicked check boxes.  If they clicked auto, I checked the accident and
cleared the illness and maternity, if they clicked the maternity, I
cleared the auto and accident and set the illness.  Etc.

In order to encapsulate this whole thing into a SYSTEM that was an
integrated whole, I built a class, passed in a pointer to all five check
boxes, and sank the click event for each check box.  I then built all of
the code to do this checking as a private function inside the class.

It turns out that I needed an identical set of 5 checkboxes in three
different forms - an Initial Data Entry (IDE) form for Long Term
Disability (a set of users), another IDE for Short Term Disability (a
different set of
users) and a central claim form where everybody came to maintain claims.
Because I had written a class to encapsulate the whole into a class I
could set the whole thing up with 3 lines of code in each form:

**in the form header
Public WithEvents ldclsValClaimTypeChkBoxes As dclsValClaimTypeChkBoxes

*** in the form OnOpen

    Set ldclsValClaimTypeChkBoxes = New dclsValClaimTypeChkBoxes
    ldclsValClaimTypeChkBoxes.Init fclsfrm, Me, chkWorkComp,
chkAutoRelated, chkAccident, chkSickness, chkMaternity

Having done that, the class instance handled all of the checking as
check boxes were checked / unchecked.  There were no event sinks
required in the form for the checkboxes, and if the rules need changing
just go to the class and everything required is right there.  Class
module header comments can explain why I am doing what I am doing
(Documentation!!!) all in one place.

NOTICE that the class was dimensioned WithEvents!!!

Public WithEvents ldclsValClaimTypeChkBoxes As dclsValClaimTypeChkBoxes

What this means is that the class raises it's own event to notify the
form that the boxes had changed.  THIS is a critical concept as well,
RaiseEvent means that a class can radiate an event in case anyone cares
to listen.

It turned out that Long term and Short term handled things a bit
differently and some recalculations in other fields were needed in STD
forms where they aren't needed in LTD forms.  By radiating an event
saying that these check boxes had changed, I could listen for that event
in the STD initial data entry form and do the recalcs, but ignore the
event in LTD IDE.

Withevents and Raiseevents are nothing magical.  They are just an
extension of what every Access developer already knows.  But once you
wrap your mind around what it can do for you, the difference in the way
you attack things can be startling (even magical).

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence
(AccessD)
Sent: Thursday, November 20, 2003 2:07 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Primer on WithEvents and RaiseEvent


Hi Guys:

An excellent article...Now I know what the 'withevents' and 'raiseevent'
can be used for other than passing error messages back  from a class.

Great stuff.
Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Wednesday, November 19, 2003 3:56 AM
To: accessd at databaseadvisors.com
Subject: [AccessD] Primer on WithEvents and RaiseEvent


Hi all

Just noted this book chapter counting several well known listmembers
among the numerous authors:

  http://accessvbsqladvisor.com/doc/13276

Beginning Access 2002 VBA: WithEvents and RaiseEvent

One of the best-kept secrets in Microsoft Access, WithEvents lets you
handle an object's events inside classes other than the form classes.
This book chapter explains what it can do for you.

/gustav



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


More information about the AccessD mailing list