bouncer@localhost.not (Larry Linson) wrote in
<1tEMb.404$4P6.399@nwrddc01.gnilink.net>:
[color=blue]
>"David W. Fenton" wrote
>[color=green][color=darkred]
> > > That is, unless you have reports, as is often
> > > the case, where the user enters values to limit
> > > the number of records in the report -- those
> > > are probably going to require that you create
> > > a separate form for each and open that form,
> > > so the user can enter the limiting values, and
> > > then you execute a DoCmd.OpenReport
> > > from that form.[/color]
> >
> > There's hardly ever a case where you should
> > need to do that.
> >
> > The best way to collect filter information from
> > a form for a report is to open that form as a
> > dialog in the form's OnOpen event and
> > change the recordsource. This makes it possible
> > to have a single dialog form that is used for
> > multiple reports. It also means the dialog form
> > doesn't have to know anything about any
> > of the reports it is used for.[/color]
>
>That's a good approach and it'll work if you have a number of
>reports all limited by the same data... for example, dates. If you
>have other "selection factors", you will either need other dialog
>forms, or you'll need to pass information to the form to be
>displayed in lieu of labels. And, in most applications I've worked
>on, there were a limited number of reports with the same
>limiting/filtering data -- a few using a date range, others using
>a geographic filter, some using a corporate structure selection,
>etc.. So, while you could not conveniently get by with one
>"selection form", you could get by with a few of them.[/color]
Well, re-usability is only a secondary benefit of my suggestion.
The main benefit is making the opening of the report a unified
event, that you don't have to know "Oh, gee, I have to open that
report with this *form* instead of just opening the report."
[color=blue]
>I suppose you could get by with one, if you did a good deal of
>code to communicate between the Report and the Form, to display
>the proper number of text boxes, or combo boxes, and the correct
>labels, etc., as well as to retrieve the appropriate data and
>build the record source. But, generally, I find it easier to
>maintain more forms and less complex code.[/color]
I have plenty of applications where these dialog forms get
repeatedly re-used. I have never used "adaptable" dialogs that
would enable/disable or show/hide particular criteria depending on
the report, because then you're breaking the implicit rule behind
the benefit of re-use, that the form needs to know nothing about
the report it is being used with.
If I *were* going to re-use a dialog and dynamically reformat it,
I'd definitely wrap the whole thing in a class module and use it as
the storage system for the data collected.
[color=blue]
>I worked on one system that had a "standard" selection form, but
>in an attempt to simplify, they had put so much on that form that
>the code to massage it for a given report was complex. And, too,
>not all the possible entries were applicable for all the reports.
>The designers should have put more thought, and more forms, into
>the process and it would have cut way back on the processing and
>VBA code, and _maintenance_ time and effort required. The
>information was picked up, validated, and processed in the Open
>event of the Reports, BTW.[/color]
I generally think it's worth it to code the dialog into the OnOpen
event (though you might want to have a bypass if the report's
filter is not zero-length, which would mean that it's being opened
with a WHERE clause) even if the dialog is used only once, simply
because it makes the dialog a "child" object of the report, rather
than the other way around. It also leaves open the possibility of
re-using the dialog, something that is much harder the other way
around.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
