[AccessD] Your favorite control behavior

Andrew,

Yes, I am (slowly) learning .net.  It's OO stuff is enough to make me drool.
Unfortunately it's database stuff is weak and I am a database developer.

Stick around (if you are an Access developer) for the framework discussion.
Access' inheritance is non-existant so we use workarounds.  If I could just
inherit the form class and add my stuff I probably would do that but I
can't.  And of course controls don't have a class at all.  Look in .net and
a control is just a class that you can inherit like any other class.
NICE!!!  Lacking that in Access, classes out in a lib is a poor man's
substitute and is what I am up to.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Haslett,
Andrew
Sent: Sunday, March 07, 2004 9:41 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Your favorite control behavior


I always thought it was "I couldn't care less".

Anyway, very interesting discussion.

John, not sure if you've looked into yet, but the .Net languages (and many
other OO languages I presume) will provide you with a lot of support for
what you are trying to implement with your framework.  Inherting your pages
/ controls from a base class will be ideal to 'inherit' common functionality
that it seems you are doing. Custom controls (reusable) alse offer the
capabilities you are creating with your framework.

I haven't looked in detail at your framework or anything - just been
browsing these discussions, but was interested to know if you've looked into
.Net yet.., as I think you would find it quite interesting.

Cheers,
A

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Monday, 8 March 2004 12:19 PM
To: Access Developers discussion and problem solving
Subject: RE: [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.

Yep, you are correct.

>The downside is needing to know the name of a control in order to be
>able
to operate with it.

To program certain functionality (such as passing in the table / field /
form to a combo for NotInList) that is correct.

>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.

I see no advantage there.  My form class scans all of my controls and loads
a class for each control.  That class hooks up all the functionality for
them.  I don't have to "make sure" I have cut the control from the right
place so that stuff is in the event properties.

>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.

So you have replaced writing a few lines of code in the Form's Open
(standard, can be cut and pasted) with dozens of cuts and pastes of controls
onto the form?  Hmmm.....  I can definitely see how this might be better....
<grin>

>You can override the 'inherited' behavior by changing the function,
>writing
a specific event procedure or passing in one or more additional optional
parameters.

Of course you can.  So can I using my framework and control classes.

>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.

That's like saying "The car has been around a lot less time than the horse
so why are we using a car".  Sure, Withevents were not around when Access
1.0 came out, and of course this is not applicable to 1.0.  More powerful
tools are handed to us year after year.  To say I am not going to use it
because it wasn't available in 1.0 is silly and prevents adapting some very
powerful tools.

Jurgen, I could care less whether you want to use this stuff.  I could care
less whether you love hooking functions straight up to the event property.
That is an option, and if that is the tool you choose to use, that is your
business.  I have explained to you why I don't touch that stuff, and why,
when I have to take over an app where the previous developer uses that
method it pains me greatly.  I used to use it, don't get me wrong, it's just
that there are tons of disadvantages and only one advantage, your "cut and
paste" advantage.  That "cut and paste" advantage isn't sufficient in my
mind to overcome the disadvantages.  In fact that advantage has been neatly
replaced by Withevents in classes!  You have a SINGLE function that you hook
to a property, and you have a bunch of functions that you hook to a bunch of
properties.  I have a class that I pass a control to.  I sink the events in
that class, then call various functions of the class from those events.  The
results are similar, but not identical.

I can for instance, turn on/off the behaviors using sysvars.  My good friend
William Hindman was using some stuff of mine and didn't like some specific
things I was doing.  I simply "switched it off" for him.  Nothing more than
"go in the sysvar table and set this sysvar = false.  His system didn't use
that behavior anymore.  Try THAT with your method.  A framework is waaaay
more than just a function hooked to an event, or even a bunch of functions
hooked to a bunch of events.  It is a whole system that works together.

My control classes talk to the form class.  The form class loads SysVars
that turn on and off functionality of the framework.  I can override a given
functionality for the entire application, or just for a given form in the
application.  The control classes "talk to" the form class and ask whether
they should exhibit this behavior?  The control class simply doesn't care
whether the behavior is turned on / off for the entire application or just
this form, all they care about is that they are supposed to exhibit the
behavior THIS TIME, RIGHT NOW.  Tomorrow the user might want the behavior
and I go turn it on using a SysVar.  TRY THAT with your "cut and paste"
stuff!!!

>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 control to a common not in list procedure
because you need to write and maintain the framework.

You are 100% correct.  I do write a whole lot more code than you do.  In
fact I write almost EXACTLY the same code you do, I just make it a part of a
whole system rather than an isolated thing that happens.  The "way more
code" is the stuff required to tie it in and make it a system.

When I design a form I don't "cut and paste" a bunch of controls so that
they get hooked up properly.  My form class loads control classes that hook
everything up for me automatically.  Whether I have one or a hundred combos
on a form, every one can, if it needs it, have any of the various behaviors
that the combo class provides.  Why in the world would I go somewhere, "cut
a control" and paste it in the form a hundred times?

Furthermore I can take ANY form, load a form class in that form's Open and
have all of my stuff just automatically applied to all of the controls on
that form!  All the combos suddenly know how to do combo stuff, all the text
boxes suddenly know how to do text box stuff.  If a given combo needs
NotInList (and MANY don't), then a single line of code passes in the correct
table / field / form for that combo to know how to do it.  Try THAT with
your "cut and paste" stuff!

I seem to remember butting heads with you in the past.  You were always
about "the last ounce of (application) speed", and I simply don't care about
that last ounce.  I am more about speed of development and ease of
maintenance.  Your "cut and paste" does allow lightweight forms.  I could
care less.  If that is what this is all about, I will hand you your "speed
advantage" and you can walk away the winner.  I will take my speed of
development and ease of maintenance and I too will walk away a winner.

I understand what you are doing, I have done it that way in the distant
past.  Listen to what I am trying to explain where frameworks are concerned,
read it, UNDERSTAND it (ALL OF IT), and then if you still love your "cut and
paste" stuff... "may the force be with you".

And may I never have to maintain your apps!  <grin>

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jürgen Welz
Sent: Sunday, March 07, 2004 6:01 PM
To: accessd at databaseadvisors.com
Subject: RE: [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