Hi Gerry,
First off, let me say that I never use Macros - I build the functionality
that I need via VBA code.
Next, one of the things that I find frustrating with the Microsoft example
databases is the total lack of any naming conventions; it often takes a
while to work out exactly what's going on and how things work because
objects have names that tell you nothing about what they are. I mention
this because I was irked by it when trying to figure out how the existing
macro for viewing reports works; if you want some background reading on
naming conventions (the commonest is the Leszynski Naming Convention (LNC)),
try the following link:
http://www.helenfeddema.com/files/accarch75.zip
The zipfile includes a free add-in that you can install to help you rename
existing objects and form controls, and a descriptive article (including
installation instructions). Add to that the use of names with spaces -
another irk, and non-standard practice among all serious developers.
Now, to the nitty-gritty: I suggest that you do this by simply copying
what's already existing in the Accounts Ledger database, and modifying as
appropriate. I don't intend to simply say "do a, b, c, ...", since you
won't learn anything from that; instead, I'll describe roughly what's
involved (in doing it via macros, as is presently done in the Ledger
database), and leave it to you to play.
The underlying objects for the existing View Reports button on the
Transactions form are:
1. the "View Reports" form, which opens when the button on the Transactions
form is clicked. This form also contains a non-visible text box which
contains the filter string (the Where Condition in the macros - see below)
built from the selected option button and the two date textbox controls in
the grpFilterOptions control, via a Choose expression. Controls which need
to respond to events (the click event of the two command buttons, and the
double-click event of the list box) have the names of the macro entered into
the event property for the control (note the syntax, with a dot between the
macro object name and the macro name).
2. a table containing the names of the reports (named "Reports"). This has
three fields, but it doesn't really seem to need them all; there's an
autonumber field ReportID which is not really necessary, a ReportName field
which contains the names of the various reports (the entries must match
exactly the names of the reports as shown in the Reports tab of the database
window), and a ReportDesc field which is empty for all records.
2. a query (named "Add or Delete Reports") which is used as the rowsource
for the listbox on the "View Reports" form. This query selects the
ReportName field from the "Reports" table. I guess they've done it this way
to simplify things; they could equally as well have set (in the Data tab of
the Properties dialog box for the listbox control on the "View Reports"
form) the rowsource to the name of the table, set the Bound Column to 2 (the
second field in the table), and (on the Format tab) set the column count to
2 and the column widths to 0; 2.5 - this will have the effect of hiding the
first field from the table.
3. a macro (named "View Reports Macro") which contains details of the
various actions to be performed on various events. As I said earlier, I
never use macros, so I'm not au-fait with their intricacies, but what's here
all seems pretty simple. The "View Reports Macro" object contains three
separate macros, and for each one, the associated objects/parameters are
shown in the bottom section of the macro design grid when the row for the
parameter is selected. Note that an entry such as "=[Forms]![View
Reports]![lstReports]" (in Report Name for an OpenReport action) means that
the report which opens is the one whose name is given as the selected item
in the lstReports control on the View reports form.
4. the various reports. Note that the report designs contain filter
parameters displayed in the header.
5. the "Reports" form, which is used to enter/edit/delete entries in the
"Reports" table - see what I mean about confusing object names; I'd have
called these "frmReports" and "tblReports" respectively.
So, to reproduce this, you'll need to create your own version of each of
these objects (you could exclude the query, if you change the properties of
the listbox on your new version of the "View Reports" form), populate your
new table (either directly or via a new frmCustomReports), set the
appropriate properties for the controls and refer to the appropriate objects
in your new macro object, containing similar macros to those in the current
View Reports Macros object.
I suggest that, if you are at all serious about being able to build or
customise an Access database application, that you get one (or more) good
reference texts for the version of Access that you are using, and study
carefully. Go to a bookshop and browse; find something that you can
understand, but which is neither too simple nor too complicated (and that
will be a personal thing, depending on your current knowledge/background).
Access does have a pretty steep learning curve, and it's likely to be
frustrating to start with. But you'll get there.
Good luck, and HTH,
Rob
PS. If you have further questions - and I'm sure you will - I suggest you
post as new questions, rather than continuing this thread. You'll likely
get more (and, since you're probably on the other side of the world to me,
faster) responses from a large group of people ready to assist. You should
also consider posting to a specific subgroup in the microsoft.public.access
heirarchy appropriate to each question; eg. there's a .macros group, which I
don't ever look at, but which might be very useful for you if you have
problems with macros.
Hi Rob,
I have a different kind of question. It has to do with Macros.
On the main transaction form (when opened), there is button linked to
a set o f reports. I would like to create another button that links
to a specific set of reports but I am not sure how to do that. Any
suggestions?
Thanks!
Gerry
<snip>
