[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