[AccessD] Framework Discussion - Dependent Objects

John,

  I'm not sure what you think I mean by "overloading", but what I'm saying
is that you have a choice:  You either build numerous classes to handle
specific behavior or you overload a single class with more properties and
methods to make it handle more then one type of behavior.

<<If a popup calendar floats your boat, build one and tie it in to the text
box class.  Have a UseCalendar property that you set the "turns on" using
that calendar for exactly the instances where you want a calendar.  However
it is that you managed to program the text box to use the calendar in some
form somewhere, that same exact code will work in the text box class.
Except that once added to the class it is available to any text box anywhere
in the app.  Set your UseCalendar property and boom... that text box will
use the calendar.  This isn't magic, just engineering effort applied to the
system rather than to one control on one form.>>

  And this was exactly my point.  Your choice was either to create a new
class in the Framework to handle a text control with a popup calendar or add
properties and methods to a single class so it can do both jobs.

<<Or are you perhaps telling ME THAT I SHOULD NOT DO THIS but it is just
fine
that Microsoft does it?>>

  I'm not telling you do to anything.  I was trying to add to the
discussion, pointing out that performance is based on design decisions that
are made in the framework.  You are taking an OOP approach and the same
fundamentals apply no matter which language your dealing with.

  I don't understand why your taking this so personally.  I never said that
what you were doing was not worth it.  I was discussing frameworks in
general.  This has nothing to do with me leaving Access for VFP, which I
have not (I still use both tools on a regular basis).  I would love to see
someone do a commercial framework for Access.  But after 10 years of
existence, one has to ask themselves why there are not a truck load of them
already.

  You asked for input about the design of frameworks and I've brought up a
few issues (performance and distribution of new versions).  If you don't
want to address them and explore these areas then fine. But if that's the
case, then don't ask for the input in the first place.


Jim
(315) 699-3443
jimdettman at earthlink.net

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Monday, March 15, 2004 9:34 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Framework Discussion - Dependent Objects


Jim,

>  So you'll end up with lots of classes, unless I misunderstanding your
intent.  For example let's start with a base text box class.  In a typical
app, you can have text boxes that can be used for: 1. Text input 2. Input of
a short date 3. Input of a short date and time.  #2 and #3 are variations of
#1 and contain some of the same behaviors and methods.  So at the frame work
level, I'm going to provide three classes or I'm going to do one class (text
box) and overload it with properties to accomplish #2 and #3.  But what your
not doing is starting with #1, then creating #2 and #3 based on #1.

Lets back up a minute and discuss this from a logical perspective.

<<snip>>