[AccessD] Your favorite control behavior

Correct me if I'm mistaken, but my understanding is that a form has it's own 
class which you can multi instance in various ways and in which you can 
create property procedures and do any thing else one can do in a class of 
your own.  It sounds not like you are creating a form class but a separate 
class to shadow the form class.  The downside is needing to know the name of 
a control in order to be able to operate with it.   The advantage of hooking 
up all default behaviors with a function is that you can pass the procedure 
a reference to the actual control for which the event is triggered so there 
is no need for collections or code to run on the form open event.  Every 
copy/paste of a control is automatically hooked up to the standard events 
without ever writing any code except the single function procedures that all 
copies of the control trigger.  You can override the 'inherited' behaviour 
by changing the function, writing a specific event procedure or passing in 
one or more additional optional parameters.  Correct me again if I'm 
mistaken, but this facility to hook up events has been around since Access 1 
whereas WithEvents is somewhat newer and more esoteric and less universally 
understood or used.  I suspect that developers coming from a Visual Basic 
background are less familiar with the advantages of this approach, 
particularly when they bemoan the lack of control arrays.  I suspect this 
facility is the reason that control arrays were never needed in Access.

Like Arthur, it looks to me like you write a great deal more code than the 
one line each of us uses to hook a contol to a common not in list procedure 
because you need to write and maintain the framework.

Ciao
Jürgen Welz
Edmonton, Alberta
jwelz at hotmail.com





>From: "John W. Colby" <jwcolby at colbyconsulting.com>
>
>Arthur,
>
>As I have been discussing in my emails lately I use a framework with 
>various
>classes.  One of these is dclsFrm which is the form class.  In OnOpen of 
>the
>form I set up the form.  Once dclsFrm is initialized it has scanned for all
>the controls and loaded a class for each control.  If I need to "program"
>the control classes, I then do so immediately after initializing the
>dclsFrm.  The whole form header looks like (error handler stripped out for
>readability):
>
>Option Compare Database
>Option Explicit
>Public WithEvents fclsfrm As dclsFrm
>
>Private Sub Form_Open(Cancel As Integer)
>     Set fclsfrm = New dclsFrm
>     fclsfrm.Init Nothing, Me, Cancel
>     If Cancel Then Exit Sub
>     With fclsfrm.Children
>         .Item("cboIDCity").NotInListData "tlkpCity", "CI_Name", "lfrmCity"
>         .Item("cboIDPrefix").NotInListData "tlkpPrefix", "PFX_Prefix",
>"lfrmPrefix"
>         .Item("cboIDSuffix").NotInListData "tlkpSuffix", "SFX_Suffix",
>"lfrmSuffix"
>         .Item("cboIDCity").DependentSet 
>fclsfrm.Children("cboIDContactCity")
>         .Item("cboIDST").DblClickFormData = "lfrmState"
>         .Item("cboIDContactCity").NotInListData "tlkpCity", "CI_Name",
>"lfrmCity"
>         .Item("cboIDContactSt").DblClickFormData = "lfrmState"
>         .Item("cboIDContactCity").DependentSet 
>fclsfrm.Children("cboIDCity")
>     End With
>End Sub
>
>Thus I dimension dclsFrm Withevents (it can raise events that I may want to
>sink in the form's class).
>
>I set the class to a new instance.
>
>     Set fclsfrm = New dclsFrm
>
>I initialize the dclsfrm passing in Me and the Cancel variable so the Init
>can cancel the opening of the form if necessary.
>
>     fclsfrm.Init Nothing, Me, Cancel
>
>If dclsFrm sets cancel true I exit the sub and allow the form to close
>
>     If Cancel Then Exit Sub
>
>If I get to that point (cancel is not returned true) then I MAY "set up"
>various control classes.  In this case I am setting up NotInList and
>dblClick events for cboIDCity, cboIDPrefix, cboIDSuffix, and
>cboIDContactCity.  I am also setting up Dependent combos for cboIDCity
>(cboIDContactCity may change if any changes are made to the city table) and
>cboIDContactCity (cboIDCity may change if any changes are made to
>cboIDContactCity ).
>
>     With fclsfrm.Children
>         .Item("cboIDCity").NotInListData "tlkpCity", "CI_Name", "lfrmCity"
>         .Item("cboIDPrefix").NotInListData "tlkpPrefix", "PFX_Prefix",
>"lfrmPrefix"
>         .Item("cboIDSuffix").NotInListData "tlkpSuffix", "SFX_Suffix",
>"lfrmSuffix"
>         .Item("cboIDCity").DependentSet 
>fclsfrm.Children("cboIDContactCity")
>         .Item("cboIDST").DblClickFormData = "lfrmState"
>         .Item("cboIDContactCity").NotInListData "tlkpCity", "CI_Name",
>"lfrmCity"
>         .Item("cboIDContactSt").DblClickFormData = "lfrmState"
>         .Item("cboIDContactCity").DependentSet 
>fclsfrm.Children("cboIDCity")
>     End With
>End Sub
>
>dclsFrm.children is filled with pointers to all classes that it 
>initializes,
>and the contents of that collection are keyed on the control name, thus I
>can just "look up" the class by indexing into the collection with the
>control name.
>
>
>John W. Colby
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
>Sent: Sunday, March 07, 2004 2:14 PM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] Your favorite control behavior
>
>
>I don't see the advantage to doing it in the OnOpen versus in the
>NotInList event of the control itself. Either way it's one line of code.
>Please explain.
>
>Arthur

_________________________________________________________________
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines