Jim Lawrence
accessd at shaw.ca
Wed Jul 13 01:29:24 CDT 2005
Hi John:
Save a copy for me. It sounds like a good read...but I guess it only works
with bound forms.(?)
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Tuesday, July 12, 2005 8:45 PM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] Framework book - was caption from code
Around the end of last year, I started rewriting my framework for the third
time, in fact I now call it C2DbFW3G meaning 3rd generation. It is Access2K
or better - A97 not supported mostly because I use RaiseEvents which are
unsupported in A97. This version is still not fully fleshed out simply
because I have ported (rewritten) the old 2nd generation framework piece by
piece as I needed the modules, and I haven't needed the form / control stuff
that I had in the 2G version.
In fact I started on it because of a project that is generating reports for
a client. The application is a report system for a call center for short
term disability insurance. I (re)wrote the call center software from
scratch but the reporting stuff kinda sorta worked and I never rewrote it
from scratch. The insurance company that hires my client to do the call
center is completely changing THEIR software, which now supports completely
automated data feeds.
In the past, my system generated Word documents with "new claim notices" and
"advise to pay" notices. These reports were generated automatically and
attached to emails to the insurer, where they were opened and keyed in to
the system. Because it was always done that way! Sigh.
It always sucked, errors on their end keying in the reports etc.
So... Since the new system takes an automated feed, fixed width fields, text
files, FTPd to a site where it is opened and loaded in to the system
automatically, I had the opportunity to rebuild this reporting thing from
scratch.
The kinds of framework things I needed for this application were distinctly
different from the framework things I needed for a typical form based data
entry / call center application. At the same time, entire pieces are pretty
similar or even identical. So I yanked the useful classes and code other
than form / control stuff from the 2G framework, took the opportunity to
clean it up a LOT, and "started from scratch", although not exactly as I
have intimated. The result is a lot cleaner, even more heavily class based,
and uses a "service plug-in" concept.
A framework is really about providing services to an application. These
services may be clearly a service, such as logging to text files, zipping /
unzipping files, encryption etc., or they may be less clearly a service,
such as a form class that loads control classes that provide record
selectors, JIT subforms, OpenArgs etc. In the end though, even these are
just services to an application. What I am trying very hard to do this time
is set up the framework to allow plug-in services where the service is
loaded if it is needed, with a "socket" kind of interface - at least for the
non-form based services.
Things like SysVars, Zip/Unzip, logging etc are really easy to do this with.
The classes exist and if the application wants a logger it asks for one. It
is stored in a collection keyed by name and the app can then use it by
calling a .log method of the framework, passing the name of the logger and
the text to log. If a logger by that name isn't loaded, it loads and then
stores the text that needs to be stored in the log file.
Like that.
It turns out that a log file like that works well for these NCN and ATP
reports. The application asks for an NCN log, gathers the data and builds
up the fixed width field strings. When each string (NCN or ATP record) is
finished, the app just writes it to the log file. When all the records are
written to the log file, the file is emailed or FTPd as desired. The log
and the email or FTP is just a service. The APPLICATION has to build ATP
and NCN reports, but it just asks the framework for a log and when the log
is done, asks the framework to email or FTP the log somewhere.
Services. Neat stuff and lots of fun to do.
As for the book, well... I have worked on a couple of books for Wrox, but
they gave a lukewarm reception to the idea of this stuff written into a
book. I am just "doing it myself" and will then pitch it when it is closer
to written. Sometimes the powers that be just don't "get" what you want to
do. Or maybe it just won't sell and I'll be sitting on a years worth of
writing. I have never seen a book like this for the Access arena so I just
want to do it.
John W. Colby
www.ColbyConsulting.com
Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow
Sent: Tuesday, July 12, 2005 10:53 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Change Reports Caption From Code
Ahhh, I can finally stop holding my breath! I threw my poor excuse of an
answer out there just to keep this thread alive, I had a feeling you had
this done in classes and I was just waiting for you to describe how you did
it. :o)
So your writing a book on it all! Can you feed some chapters out on it for
proof reading purposes or something?
John B.
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Tuesday, July 12, 2005 8:01 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Change Reports Caption From Code
>You may wish to consider using OpenArgs.
In my framework I use a pair of classes for this purpose. Openargs (in my
system) are in the format ArgName1=ArgValue1;ArgName2=ArgValue2;... With as
many arguments as the developer needs to pass in to the form.
clsOpenArg (singular) is a simple class with a name/value pair of variables
and properties to read them back out. clsOpenArgs (plural) is the
"supervisor" It is passed the openarg string by the form class. It parses
the openargs and creates an instance of clsOpenArg for each openarg passed
in, saving each instance in a colOpenArgs using the argument name as the
key.
The nice thing about using a class pair like this is that the form (or
report) then has a place to go to retrieve the arguments in a consistent
manner. You (the developer) no longer need to parse arguments inside any
form that has arguments passed it, just instantiate the supervisor
(clsOpenArgs (plural)) and pass in the openargs string (in OnOpen of the
form / report) and then just read out the argument values using variable
names that you know exist because you set them.
For example:
OpenArgs - FormCaption=MyForm;lblCompanyName=Colby
Consulting;...MoreArgs=MoreValues;
In the form or report header, you dim an instance of the supervisor class
Dim lclsOpenArgs As clsOpenArgs
In OnOpen you set up the class and pass in the openargs, then just reference
the arguments:
Private Sub Form_Open(Cancel As Integer)
lclsOpenArgs = New clsOpenArgs
With lclsOpenArgs
.OpenArgs = Me.OpenArgs
...the .OpenArgs method accepts the openargs string and parses them, placing
them into OpenArg class instances, then placing those class instances in a
colOpenArgs keyed on the argument name.
lblCompanyName.Caption = .Arg("lblCompanyName")
Me.Caption = .Arg("FormCaption")
End With
End Sub
As you can see, the form code then just reads the argument values out by
passing in the name of an OpenArg it expects to receive and does something
with that value.
You can have one or 40 openargs, and clsOpenArgs just parses them and gets
them ready to use. The form can read the values out of the supervisor class
clsOpenArgs by name. The form class can read the values out anywhere they
are needed, in any event or even in functions that do something complex.
Another trick I use is to have a method in clsOpenArgs that looks up the
argument names in the properties collection of the form. If the name
matches a property, the property is set to the value of the argument. This
allows me to open a generic form and setup things like AllowEdits,
AllowDeletes etc using arguments passed in to OpenArgs. Not always useful,
but when I need to do something like this it is just automatic.
Classic class programming.
This code and more will be found in a book I am madly (but slowly) writing
to be available at a bookseller near you sometime next year.
John W. Colby
www.ColbyConsulting.com
Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Josh McFarlane
Sent: Tuesday, July 12, 2005 6:53 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Change Reports Caption From Code
On 7/12/05, Bob Heygood <bheygood at abestsystems.com> wrote:
> Thanks to all who responded. The on open event is what I used. I thot
> of it earlier, but thot twice about using a global variable. Not to
> start another rant/discussion, but I feel this is a good example a
> good use of a global.
>
> I am creating 79 PDFs from code, which involves opening a report. The
> neat news is that the reports caption property is what Acrobat uses
> for the resulting file name. Hence my need to change the caption each
> time I programmically open the report.
>
>
> thanks again.
>
> bob
You may wish to consider using OpenArgs. When calling the report via code,
you can pass it arguments via the DoCmd.OpenReport, then with the OnOpen
code, change the caption of the current report. I do this with an form that
I use to determine date range (changes form caption to be the name of the
report it is called to open) and it works like a charm.
DoCmd.OpenReport ReportTest, acPreview,,,,"Report Caption"
Then in the on open handler:
Caption = OpenArgs
or something similar to fit your needs.
--
HTH
Josh McFarlane
"Peace cannot be kept by force. It can only be achieved by understanding."
-Albert Einstein
--
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