[AccessD] Withevents vs Implements

Hey John,

I was reading the chapter you referred us to and I wondered who wrote the
part about building the event handler stubs. It says: "The easiest way to
get an event handler built is to simply place a control of the type you
desire in a form, name the control exactly what you will call it in your
class, open the properties box for that control, then use the code builder
to build the event stub. Now cut the event stub out of the form's module and
paste it into your own class."

This cumbersome procedure works, but there's a much simpler way to do it. In
the class that's got the WithEvents objects declared, select the object name
from the left-hand combobox in the module window. The right-hand combobox
will then list all the possible events for the object selected. If you then
choose one of those events a stub event handler will be created in the
module, complete with all the parameters it needs.

I'm surprised no-one noticed that before! Something to update in the 2nd
edition? :-)

Lambert

> -----Original Message-----
> From:	John W. Colby [SMTP:jwcolby at colbyconsulting.com]
> Sent:	Tuesday, January 13, 2004 9:05 PM
> To:	Access Developers discussion and problem solving
> Subject:	[AccessD] Withevents vs Implements
> 
> 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/A6CBCC9F0ED68B2E88256DD4007C
> 2FDD
> 
> 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
> 
> 
> 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com