[AccessD] Your favorite control behavior

Arthur Fuller artful at rogers.com
Tue Mar 9 13:44:29 CST 2004


I could be of some help in the move to SQL too, JC.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Monday, March 08, 2004 7:29 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Your favorite control behavior


Are you a proficient programmer?  If so I'd love to work with you, just
follow the Framework discussion as it unfolds.  I have just about
decided to rebuild my own framework for the 3rd time (making it a 3rd
generation design
;-) and will be doing so via this discussion.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mike & Doris
Manning
Sent: Monday, March 08, 2004 9:01 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Your favorite control behavior


I'm pretty SQL savvy... I'd be interested in helping you out.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Monday, March 08, 2004 7:45 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Your favorite control behavior


You are correct however I can't efficiently do that since I don't
understand the "working with" SQL Server enough to get anywhere.  I have
a client who is moving one of my apps to SQL Server.  It would be nice
to be able to get the framework "SQL Server compliant" whatever that may
mean.  Unfortunately they are using A2K and will continue to do so for
quite some time I'm afraid.  And I squeeze every bit of "interface" out
of Access using things like queries that reference controls on forms,
queries that reference my own custom VB (or for that matter Built-in)
functions.  Both of these are no-nos when working with SQL Server.  So
it is very much a combination of making the framework itself "data store
independent" as well as MY learning how to replace what I do with what
will work with SQL Server (or rather non-jet) data stores.

For BOTH, I could use an expert in squeezing the last ounce of
"interface" out of non-Jet data stores.

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: Monday, March 08, 2004 1:56 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Your favorite control behavior


>>I'd LOVE to work with an extremely competent SQL Server developer /
programmer in
>> doing this though since I am going to need this functionality but 
>> don't
know SQL Server that well

I don't think its SS as much as interfacing with the (OLEDB) driver used
to communicate between Access and SQL.  That's where your equivalent
recordset behaviours come in.

Unless youre talking about wrapping your functionality in Stored Procs
using a disconnected framework...


-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Monday, 8 March 2004 4:26 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Your favorite control behavior

The answer to ADO is yes... with the exception of the form
RecordsetClone property which is by definition DAO.  I use ADO
exclusively in my current framework except for the recordsetclone stuff.
I use recordsetclone to get a handle to the current recordset, as well
as the current position of the form (what record is displaying) and use
that to "move" the form to display a different record etc.

As for unbound, hmmm... it probably could.  I use a lot of tricks in my
framework such as looking at the field that the control is bound to
discover the field name, and now that I know how to do so (using DAO)
drilling clear down to the table name and field name.  So the answer to
that is probably, but you might lose a lot of neat functionality.

I'd LOVE to work with an extremely competent SQL Server developer /
programmer in doing this though since I am going to need this
functionality but don't know SQL Server that well.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence
(AccessD)
Sent: Monday, March 08, 2004 12:09 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Your favorite control behavior


Hi John:

I have always liked your framework structure concept. I have not been
too interested in pursuing that application deployment as, and do not
take this the wrong way, most of my work is with SQL server BEs and,
correct me if I am wrong, but at first blush, your framework is designed
to manage 'bound' DAO programs. My apps may or may not bind the
recordsets and these recordset are used to populate the forms...one step
removed. Also, I use ADO almost exclusively.

Does your framework handle or can be made to handle ADO and Unbound
forms? (but bound (qualified) recordsets)

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Sunday, March 07, 2004 6:54 PM
To: Access Developers discussion and problem solving
Subject: RE: [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


--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

IMPORTANT - PLEASE READ ********************
This email and any files transmitted with it are confidential and may
contain information protected by law from disclosure. If you have
received this message in error, please notify the sender immediately and
delete this email from your system. No warranty is given that this email
or files, if attached to this email, are free from computer viruses or
other defects. They are provided on the basis the user assumes all
responsibility for loss, damage or consequence resulting directly or
indirectly from their use, whether caused by the negligence of the
sender or not.
--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list