View Reports from from listbox or dropdown

[DD]

Hi
I want the user to be able to view all reports from a form either by
way of a list box or dropdown or ??
any help please

DD

[DFS]

Your list or dropdown rowsource:

SELECT [Name] FROM MSysObjects WHERE [Type] = -32764 ORDER BY [Name];
"DD" <da**********@bigpond.com.au> wrote in message
news:14**************************@posting.google.c om...

Hi
I want the user to be able to view all reports from a form either by
way of a list box or dropdown or ??
any help please

DD

[David Deacon]

View Reports from from listbox or dropdown
Ok, the user creates a new rpt from the wizard,the backend is hidden.
Now i want the new rpt "whatever name to populate in the list box,,or
give access to the user to all the rpts and they choose their new rpt.
All this is done via a form

big job or what?
DD
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Larry Linson]

Little job: you pick up the name of the report from the combo or list box in
its AfterUpdate event and use it in a DoCmd.OpenReport. 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.

Larry Linson
Microsoft Access MVP

"David Deacon" <da**********@bigpond.com.au> wrote in message
news:3f***********************@news.frii.net...

View Reports from from listbox or dropdown
Ok, the user creates a new rpt from the wizard,the backend is hidden.
Now i want the new rpt "whatever name to populate in the list box,,or
give access to the user to all the rpts and they choose their new rpt.
All this is done via a form

big job or what?
DD
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[DFS]

"David Deacon" <da**********@bigpond.com.au> wrote in message
news:3f***********************@news.frii.net...

View Reports from from listbox or dropdown
Ok, the user creates a new rpt from the wizard,the backend is hidden.
Now i want the new rpt "whatever name to populate in the list box,,or
give access to the user to all the rpts and they choose their new rpt.
All this is done via a form
If they can use the Report Wizard, the database window is open, right? So
they
already have Access to all the reports and there's no need for a form.

big job or what?
DD
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[David W. Fenton]

bo*****@localhost.not (Larry Linson) wrote in
<qx***************@nwrddc02.gnilink.net>:

Little job: you pick up the name of the report from the combo or
list box in its AfterUpdate event and use it in a
DoCmd.OpenReport. 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.

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.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

"David W. Fenton" wrote

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.

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.

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.

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.

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.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

bo*****@localhost.not (Larry Linson) wrote in
<1t***************@nwrddc01.gnilink.net>:

"David W. Fenton" wrote

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

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.

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

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