Drew Wutka
DWUTKA at marlow.com
Fri Nov 21 14:45:22 CST 2003
Well put. It took me a little bit to catch onto building my own classes,
and using events. Now it is just second nature, and I am boggled at what I
did before!
The real fun I've had lately is using VBScript's 'version' of a
Class/collection. Slightly different, but still pretty adequate.
Drew
-----Original Message-----
From: John W. Colby [mailto:jcolby at colbyconsulting.com]
Sent: Thursday, November 20, 2003 8: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