Maybe this is one case where setting a global
variable IS appropriate?!
FWIW i think having the dataset "outside" sort of
violates
the principle James argued earlier that everything should
be
visible within the report unit. Because
otherwise the
function of the report is dependant on "stuff you can't
see"
like the details of the query and field definitions of
the
outside dataset.
But if you insist on doing that - there are some ways
to pass the thing in. You don't have to resort to globals
the way a VB programmer probably would
You can:
1. Make the dataset a property of the form
containing
the quickreport component and set that
property
after you create the form but before you
show it.
2. Make the dataset a parameter of the constructor
of the form and have the constructor use
it to set
things up when you create the form (or at
least
save it in a private field)
3. If the form is modeless and you want to be
able
to change the dataset without
destroying/recreating
the form you can add a method to the
form
and include the dataset as a parameter to
the method.
4. you can include a procedure in the same unit as
the
form containing the quickreport (but not
a method
of that form) that creates an instance of
the form
and accepts the dataset as a
parameter. Since
it's in the same unit, it will have
access to all
the forms private fields just as a method
would
and could set a private field (much
as a constructor
would)
5. If you won't be invoking the QR from lots of
different
places, consider putting the QR
component on the
SAME FORM as the unit that will invoke it
- but "off camera"
(i.e. beyond the borders of the
window so it doesn't
display). This
won't inhibit the "preview" function
at all - it will still
show. And it eliminates
the need to "pass" a lot of information
between
forms when you generate the
report.
I'd probably favour 1 or 5 - but not sure there's a
compelling case to be made for preferring any one of
these
over another.
-ns
