[AccessD] Setting Default control sizes in advance

John Colby jwcolby at ColbyConsulting.com
Fri Apr 7 17:33:16 CDT 2006


>  I was thinking more in terms of execution speed.  For the example at hand
(and it's not a great example, but you'll get the point), if I have an app
that doesn't need the point size modified ever, then anything that executes
to maintain that feature is just a waste.   Depending on the framework and
what it provides, it can be the difference between a sluggish app and one
that is snappy.

I understand that concern.  What I can tell you though (from extensive
testing) is that it takes under 1/2 millisecond to load an "average" class
instance.  Thus you can load 2000 class instances in under a second.  A lot
of what a class does it does as it loads - modifying how things work etc.

The other thing to understand is that you can, using the same SysVars I have
been discussing, turn on/off functionality, either for the entire FE, or on
a form by form basis.  IOW I can tell the APPLICATION to use date
formatting.  What does this mean?  In order to do date formatting, DAO has
to drill down into the bound recordset and discover the data type for
specific types of controls.  Obviously it only does this for forms that can
possible display a date, which means (in my framework) only text boxes.  The
form has a control scanner.  When the scanner function is called, it checks
whether THIS FORM is supposed to use date formatting.  If so it starts
scanning for controls and loading a class for those controls for which a
class exists (most).  As it discovers TEXT BOXES, it discovers which field
the text box is bound to and drills down to discover the data type.  If the
data type is a date, then it reads the APPLICATION SysVar for date
formatting and plugs it in to the property of that text box.

The point of all this is that yes, the framework (form class and text box
control class) have to do this processing, but it is focused.  ONLY if the
APPLICATION date formatting is turned on and ONLY if this form is supposed
to format dates, and even then only specific controls.  Because I cache all
framework and Application SysVars in a class, accessing one or all of the
variables is virtually instantaneous.

>Frameworks are great and do solve a lot of problems, but I've found that
you need to be very careful not to overbuild.  

What you have to be careful of is that you have switches (SysVars) that
entirely turn on / off the features.  Having an actual framework though
means that the switches are loaded at Init of the application.  I typically
have 50 to 100 Application SysVars and 50-100 Framework SysVars.  The load
time for that is negligible.  As any given form loads, it searches all of
the APPLICATION SysVars for the form's name in the SysVar name.  Again, if
there are 50-100 SysVars, the var names are about 10 - 20 characters long
plus the length of the form name so again, the time to find form specific
SysVars is negligible.  I have a function where I "define" which SysVars are
required for a form.  As I build new form functionality that requires a
SysVar, I go to that function in the form class and "load" that SysVar into
a SysVar collection in the form class itself.  Thus, like the framework
itself, by the time the form finishes loading it has its own private
collection of exactly and only the switches (SysVars) that apply to it.  All
of this kind of processing may sound like it slows things down but in fact
it speeds things up.  SysVars, once loaded by the Framework are never again
loaded from the disk.  Forms look in the framework SysVar collections as
they load.  Code functionality looks in the form's SysVar collection to
determine what the form needs to do.

>Of course the trade-off is that it takes me a little more work to hook
things up.

I don't know what you have to do to hook things in but all I have to do is
turn on / off a SysVar.  Is your method truly just a "little" more work?

At any rate, my purpose is not to "convert the heathens".  I simply find
that having stuff loaded and ready, with "services" available to the
application is a very powerful concept.  There are many people that simply
aren't capable of implementing their own framework, and to them I suggest
learning about libraries and at least do that much.  Classes provide an
additional level of "setup/cleanup/encapsulation" that is very powerful.
Until I actually used them I could not understand why or how I would use
them.  Once I started using them I cannot imagine how I could survive
without them.

I still have modules of course, but any "system" now goes in one or more
classes.

John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Friday, April 07, 2006 3:47 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Setting Default control sizes in advance

John,

<<Performance - I will
argue that one since the total time to load all of the classes I mention is
under a second at framework init and well under 1/2 second for all of the
classes for a given form, even complex ones.>>

  I was thinking more in terms of execution speed.  For the example at hand
(and it's not a great example, but you'll get the point), if I have an app
that doesn't need the point size modified ever, then anything that executes
to maintain that feature is just a waste.   Depending on the framework and
what it provides, it can be the difference between a sluggish app and one
that is snappy.

  The general problem with frameworks is that you want to use it on
everything (and there in lies it's power).  But as a result, as you toss in
anything you need now and might need in the future, it just becomes more and
more bloated for each application in general.

  Office is a great example of how that gets out of control; at one point,
something like 90% of the features in office were never used by most people.
That 90% to them was just a waste.  Microsoft combated this to a certain
extent by only installing a limited feature set and having an install on the
fly if it's needed, but they still waste a lot of cycles checking the state
of things.

  Frameworks are great and do solve a lot of problems, but I've found that
you need to be very careful not to overbuild.  In regards to Access, I have
many of the same features that you have, but their in small discrete modules
that I can load into an app as needed, keeping it somewhat light weight.  Of
course the trade-off is that it takes me a little more work to hook things
up.

  With VFP, I use a full blown framework with a truck load of features and
because it is a compiled language, the performance hit isn't that great and
I can get away with it.  But I'd hate to use something like that with
Access.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
Sent: Friday, April 07, 2006 1:09 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Setting Default control sizes in advance

Uhhh, yep.  Of course I wasn't trying to solve all of those other problems.
I solved one, then another then another etc.  I started with a simple
library like many developers do.  It was truly only when I finally figured
out Withevents (which REQUIRE classes) and now had a grasp of classes (as
implemented in Access anyway), that the framework really began to happen.

Complexity, yes of course.  Classes, yes of course.  Performance - I will
argue that one since the total time to load all of the classes I mention is
under a second at framework init and well under 1/2 second for all of the
classes for a given form, even complex ones.  What a lot of people don't
know is that the CODE for a class only loads once.  The entire class loads
the first time it is used, and remains in memory after that so it isn't like
if I load a form with 40 controls I have to LOAD the 40 control classes over
and over again. The form class loads once, the combo class loads once, the
text box class loads once, then the VARIABLE/CONSTANT portion is created for
each class instance.

Frameworks are a tool, a very powerful tool, but certainly not a panacea.
OTOH, cutting and pasting code into forms or modules in each FE is no
panacea either.  There are developers out there that only work on a single
FE.  A framework is much less useful there since you don't need to apply the
same functionality to a second application.  For anyone maintaining more
than one application, a "library" is almost a requirement, and a framework
is simply the next (HUGE) step up in functionality.

John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Friday, April 07, 2006 12:21 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Setting Default control sizes in advance

John,

  It's only silly to say if your trying to solve all those other problems.
And while a framework does solve a lot of problems, it also creates some of
it's own; performance, complexity, class design, etc

  Frameworks are not the pancrea that everyone believes.

Jim.  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
Sent: Friday, April 07, 2006 9:47 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Setting Default control sizes in advance

>No need to spend hundreds of man-hours building a framework! <vbg>

LOL, what a silly thing to say.  There are hundreds of reasons to spend
hundreds of hours building a framework, this is just one of them.

Now, answer the question for EXISTING projects.  My answer works for ALL of
my projects because ALL of my projects use my framework.  Not only can I do
this if I want to, I can and do have combo double-click and notinlist event
handling, when forms pop up for my combo double click it can take you to the
exact record that the combo is currently displaying (to edit it for
example).  When handling the NotInList event and popping up a form to add
new data, it can find the control that the typed in data belongs in and
place it in that control so the user does not have to type it over again.  

My forms can have a record combo.  Copy and paste a combo and a text box
onto the form from my template form, bind the control to the autonumber PK
and set the combo's data and the combo will just function as a record
selector, automatically.  

Set a sysvar and change the date format in every text box that needs the
date formatted in a specific manner.  Do the same to set a date mask.  

How about dbl-click to open a calendar, which automatically passes back the
calendar value to whichever text box opened the calendar?  My framework does
that.

Need a form to have automatic OpenArgs parsing and preparation for use?  My
framework has that.  I can open a form (as we discussed in this email group
a few weeks ago) and just pass in Openargs which the opening form
automatically applies to its properties.  Pass in "Allow Edits=True;Allow
Deletions=False;AllowAdditions=False;" as the Openargs when you open a form
and it sets itself up as an edit only form.  Pass in "Data Entry =True,Allow
Edits=True" as the Openargs when you open a form and it sets itself up as a
data entry form.  JUST THAT SIMPLE.  Do YOUR forms allow you to do that?

How about the ability to automatically requery dependent objects when
something changes?  My framework has that.  I can, in ONE line of code per
dependent item, tell combos, forms and lists to be requeried when another
object changes state.    Not only that, but if THAT "dependent" combo has
combos (or forms, or lists) dependent on it's value, they can be requeried
automatically.  Using this functionality, I can if I want to have another
FORM requery itself when OnCurrent of the existing form fires.  ONE LINE OF
CODE to tell the current object that some other object is dependent on it
and to requery that object if the current object changes.  Yep, my framework
does that.

Want to be able to make a form editable by one group of people but not
another group?  How about hide / unhide a command button, tabs on a form or
other controls based on what group (supervisors?) a person belongs to.  My
framework does that.

Ever needed to have information specific to an application displayed on a
report?  Company address / phone / etc?  Application SysVars.  Add a new
SysVar record in the Application SysVar table and it is instantly available
to the application for whatever it needs.  It takes me oh.... About 2
seconds to add a new sysvar.  I know people who add new fields in a table to
do this!!!

HUNDREDS OF REASONS to build a framework.  My framework allows me to do
things in 10 minutes when setting up a form that will take you HOURS for
each and every form you design.  OR... You just don't give your client that
functionality.  

There are those that program the same solution over and over and over and
over (and over) and then there are those that use (at the LEAST) a library
(which is a casterated framework), or if you really want to work
efficiently, you use a framework.  

Sorry, but to say "No need to spend hundreds of man-hours building a
framework" displays a huge ignorance of what can be done if you use one.  

And the sad part of that statement is that I do nothing more than anyone
else does really.  I discover a need, I design a solution.  But instead of
placing the solution in the application (if the solution generalizes) I do
it in the class for the object that needs the solution.  DblClick and
NotInList for the combo goes in the combo control class.  I NEEDED THAT, I
designed it ONCE, I placed it in the proper class, and now it is available
to every front end I develop.  I needed SysVars.  I designed a class system
to do that and now I can have none, one or a dozen SysVar tables.  My
framework always has one and my app always has one.  The framework
automatically loads and initializes them on the Framework Init.  And I can
build others for special purposes as needed.

?"No need to spend hundreds of man-hours building a framework"?  I sure
can't think of any reasons to do so,but then I'm not very imaginative.
<grin>

John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert
Sent: Friday, April 07, 2006 9:45 AM
To: 'Access Developers discussion and problem solving'
Cc: 'Arthur Fuller'
Subject: Re: [AccessD] Setting Default control sizes in advance

There's actually a much simpler way to do this, and it only requires you use
the AutoFormat feature.

Here's the drill:

Design a form with the font and colors and whatever that client1 want, and
then save it as an autoform form design, calling the style  "Client1" (you
do that by selecting AutoFormat from the Format menu and then hit the
'Customize' button.

Then do the same for Client2, design a from to suite that need and save it
as an autoformat style. These form styles are global to Access. You will see
them available in every application you work on.

Now, whenever you want to build a form for Client1 open up their
application, select one of the existing forms, and choose the client1 style
from the AutoFormat dialog. You do this because, having made a choice in the
AutoFormat dialog, that choice becomes the default style that will be used
by the form wizards.

Then when working on Client2's application, do the same thing - select their
style from the Autoformat dialog, and presto, you can build forms to their
liking with the wizards.

No need to spend hundreds of man-hours building a framework! <vbg>

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
Sent: Friday, April 07, 2006 2:05 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Setting Default control sizes in advance


Arthur,

>Solutions requested!
>Client A wants 12 point Arial everywhere.
>Client B wants 10 point Times Roman everywhere.

Frameworks and SysVars.

I have not done that specific thing, but since my framework loads a class
for each form instance and each control type, for each instance of that
control type, it would be trivial for the text class to set the font/pitch
etc as the class loads.  That is the framework part.

SysVars say "for this FE make this property this specific value".  In other
words, I can have a SysVar named "CtlTxtBoxFont" the value of which is
Ariel, and another SysVar named "CtlTxtBoxFontPitch" the value of which is
12.  The clsFrm would have to be programmed to know about this SysVar, and
load that pair of SysVars,into its SysVar collection (each form class has a
collection to hold SysVars specific to that form), and then the clsCtlTxtBox
would have to ask the form what Font and Pitch to use.

I actually do this kind of thing, and in fact have the ability to have
SysVars specific to a particular form.  I do this by having a generic SysVar
such as CtlTxtBoxFontPitch which is set to 12 in the SysVarTable.  When the
form loads it looks for SysVars with its (the form's) name in the
SysVarName, for example frmClientCtlTxtBoxFontPitch.  Since When the
frmClient loads it scans all the SysVars looking for its name in every
SysVar.  If it finds any it strips its name out and "overrides" the generic
value with the value specific to itself.  Thus while all forms will load
CtlTxtBoxFontPitch and end up with a value of 12, frmClient may simply have
so many controls that it isn't feasible to use a 12 pitch so I can set
frmClientCtlTxtBoxFontPitch to 10 and only frmClient will use a 10 pitch
font.

I actually have this capability set up in my framework (SysVars and the
ability to override them for any specific form). For me it would be almost
trivial to set up to do something like you propose.

I did a similar thing with date formats.  Using DAO I drill down to discover
what type of data is being pulled out (for text boxes specifically).  If the
data type is a date, I have a default date format defined in a SysVar.  Thus
I can set a consistent date format via a sysvar, and if the client wants a
different data format, it is a simple matter of changing a single sysvar.

A framework is a very powerful concept and once set up and functioning can
allow implementation of behaviors that vary from front end to front end and
client to client.  

Sysvars allow the programmer to have "steering logic" in the application.
With default values in the SysVars you can have your applications "just
work" a specific way, and yet easily override that for a specific reason,
even down to the form level if desired.

John W. Colby
www.ColbyConsulting.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


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