[AccessD] Setting Default control sizes in advance

Jim Dettman jimdettman at earthlink.net
Fri Apr 7 11:21:26 CDT 2006


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





More information about the AccessD mailing list