Creating Reports programatically

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

When you programatically create a report using the CreateReport function, the
PageHeader and footer sections are, by default, turned on. How do you remove
them? Also, how do you change the name of the report?
 
Furthermore, I tried setting that section's Visible property to false and
that didnt hide the section. When I set the section's Height property to 0,
the section shrinks to nothing but in design view, the header and footer bars
are displayed.
 
JonWayn said:
Furthermore, I tried setting that section's Visible property to false and
that didnt hide the section. When I set the section's Height property to 0,
the section shrinks to nothing but in design view, the header and footer bars
are displayed.
Click to expand...


A section does not disappear in design view just because you
set it's Visible property to No. The property is only used
when the report is previreved/printed. As long as the
sections exist, the header/footer bars will always be
displayed in design view.

You can toggle the Page Header/Footer sections by using:
DoCmd.RunCommand acCmdPageHdrFtr

Rename the report by using:
CurrentDb.Reports(rpt.Name).Name = "newname"

Are you aware that CreateReport should never be used in a
running application? CreateReport is only to be used in
wizard procedures that you use to help yourself design a
report, not in response to a user's actions (e.g. button
click).
 
The RunCommand solution you submitted works just fine. However,
Reports("ReportNameOrIndex").Name = "NewName" complains with the message "The
property is read-only and can't be set" (BTW, Reports is an object property
of the Application object and not a Database object).

Finally, can you explain why its not a good idea to attach a CreateReport
routine to the click event of a button? What harm is done?
 
What harm? You want to know what harm creating and saving
heavy duty objects such as form and reports can do to a
running application? I don't think I can count the ways,
but here's some of the top ones.

Orders of magnitude increased chances of corruption.

Potentially massive bloat.

Requires that the front end db be Compacted much, much
more frequently. Compact is a really heavy duty operation
that can also go drastically wrong.

Creating form/report objects is not allowed in an mde or
runtime installtion.

It is easier/faster/safer to use a precreated report and
just manipulate report and/or control properties than it is
to create a new object and worry about the consequences.
 
Back
Top