[AccessD] Withevents vs Implements

John W. Colby jwcolby at colbyconsulting.com
Tue Jan 13 20:04:37 CST 2004


Robert,

>Why not use Implements instead of WithEvents?

They are not the same thing at all.  Implements is interface inheritance,
i.e. subclassing the exposed global data and method DEFINITIONS of an
object.  In some circles it is also called a Contract - "I agree to provide
similar functionality and data as the object that I am implementing - plus
something additional that I want to add".  Unfortunately, unlike real
inheritance where you also get the actual code of the parent object (if you
don't override it), in Implements you don't.  If you want that code you have
to cut and paste it into you own subclassed object (if the source is even
available to you).  Yuk.

Withevents is nothing more than the ability to sink events from one OR MORE
objects in your own class.  I am wrapping an entire object (or at least some
of it's events) inside my class.

One of the objectives of object oriented programming (of which inheritance
is a technique), is encapsulation of all of the data and code required to
implement an "object".  Encapsulation simply means placing everything in one
place, but it also means hiding implementation details from view.

When a combo box double click event occurs (in my framework) my class for
the combo control MAY open a form to allow the user to add new items to the
table that contains the data for the combo.  Likewise that same form can be
used to EDIT (or delete) the data in that table.  Either way, the form is
opened modal (you can't do anything outside the form) and when that form
closes, the combo is requeried so that the latest contents of the table are
contained in the combo.

How is all that done?  Who cares?  All that the developer needs to know is
how to cause the combo class to use that functionality.  In the case of my
framework, it is caused by passing a form name to the combo class through
one of it's methods.  Doing that sets up the combo to "know" that if a
double click occurs it should open that form.

So my class has a variable to hold the name of the form to open and has a
method to pass in the name of the form.  Equally importantly, my combo class
sinks the double click itself and runs code that opens that form IF the
variable contains a string of length > 0.  If it DOESN'T have a form name to
open, it puts up a message box telling the user they don't have permission
to edit the data behind the combo.

It happens that I use autonumber PKs throughout my databases.  As a result
the column(0) of the bound combo contains the PK of the record currently
selected in the combo.  When (if) the form opens, the combo class passes
that PK of the record that is currently selected in the combo to the form
(as an openarg, in the same format that ADH used for tags) , and the form's
class "moves" the recordset of the form being opened to display that record
and sets the focus into that record.  This allows the user to not only open
the form using a DblClick, but be right there at the data they need to edit
(if for example the data is wrong - a misspelled name for example).

As you can see, having a class to wrap a combo up in can be a pretty useful
thing.  All this functionality is just there, available to me at all times.
I write this kind of code once, then all combos throughout my application
have this functionality.  How it happens is hidden from the developer (me in
this case), I don't have to remember how to do all this stuff, the class
knows how.  I don't have to remember to call a function in an event stub in
a form somewhere, if a class is instantiated for that combo it has that
functionality.

Withevents is the key that allows me to sink that DblClick right inside my
class so that I am not having to remember to call functions to get this
stuff to happen.

Believe me, I used to do pretty much the same thing without classes, just
calling functions from event stubs in the form itself.  In fact I wrote an
event stub insertion wizard to build these function calls specifically for
my framework (C2DbFrameWiz) and insert them into the form.  Believe me again
when I say that method of programming isn't even in the same league as
classes and Withevents.

LEARN THIS STUFF, you won't regret it.  BTW, Withevents is available in VBA
(Excel, Word etc.), VB as well as VB.NET so it's not something you will
learn just for Access.

Again my sincere thanks to Shamil who prodded me to figure this stuff out
and provided sample code to get me started.  I repeat, I would not be where
I am today as an Access programmer without Withevents and Classes.

BTW, I wrote a chapter for this stuff (Withevents) for Beginning Access 2002
VBA, Wrox publishers, ISBN 1-86100-821-X.  The entire chapter was published
in Advisor (published on my birthday in fact).

http://accessvbsqladvisor.com/Articles.nsf/dp/A6CBCC9F0ED68B2E88256DD4007C2F
DD

Watch for line wrap.

Of course you could just buy the book.  <grin>

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Robert Gracie
Sent: Tuesday, January 13, 2004 4:45 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] =function() in .onclick


Hello All,
 Since I'm just learning this type of programming technique I thought I
would ask a question...

  Why not use Implements instead of WithEvents?  My limited understand of
WithEvents is that they will not return functionality unit they (the event)
has completed processing... Since I'm just at the "door" so to speak with
learning how to use and incorporate these new (to me) programming techniques
into my work, I really want to start out using the "best" technique...


Robert Gracie
www.servicexp.com





More information about the AccessD mailing list