Difference between detail_print and detail_format method on reports

  • Thread starter Thread starter Luke Bellamy
  • Start date Start date
L

Luke Bellamy

Hi - I would like to write some text over a report and wondering if I should
use detail_print or detail_format? but before that I guess I should
understand
the difference between the 2 methods?

My code works fine in both of these.

Thanks
 
For each record, the section's Format event runs first. In this event,
Access calculates how much space is needed to fit any controls that CanGrow
or CanShrink, and figure out how to manage other properties of the section
such as Force New Page and Keep Together. It is then able to determine
whether the section will actually fit on the page. If it cannot fit, Access
aborts the event, prints the current page without this record, and then runs
the Format event *again* to calculate how to place the record on the new
page. The report's runtime properties NextRecord, MoveLayout, and
PrintSection are also involved in this process.

Once Access has a solution for the record, the section's Print event fires
when the record is actually placed on the page. This event is too late to
add text that may need extra/less space (to shrink or grow), because that's
already been calculated. However the event is much less likely to run
multiple times (because a solution has already been plotted.) It can run
multiple times for the same record if the report's NextRecord property is
set to False.

Both events provide a counter for how many times it ran (the FormatCount and
PrintCount arguments), and there is also a Retreat event to indicate that
Access is back-tracking.

In general, use the Format event of the section to add text to an unbound
control, because it can then shrink or grow.

If you want to add text or graphics to a specific location on the page
(regardless of how the records are placed), use the Page event of the
report.

The report's Top property lets you know how far down the page this section
is falling, and you can read that in Format or Print. It is measured in
twips, where 1440 twips = 1 inch.

Do not use these events to programmatically accumulate totals over several
pages, nor to repeat the sections multiple times for some records. If the
user views/prints only some pages of the report, the events for the skipped
pages may not fire, so the totals/layout can be wrong.
 
Great... thanks Allen. Thats clears up all my questions.

---------------
Luke Bellamy
Newcastle, Australia

Allen Browne said:
For each record, the section's Format event runs first. In this event,
Access calculates how much space is needed to fit any controls that
CanGrow or CanShrink, and figure out how to manage other properties of the
section such as Force New Page and Keep Together. It is then able to
determine whether the section will actually fit on the page. If it cannot
fit, Access aborts the event, prints the current page without this record,
and then runs the Format event *again* to calculate how to place the
record on the new page. The report's runtime properties NextRecord,
MoveLayout, and PrintSection are also involved in this process.

Once Access has a solution for the record, the section's Print event fires
when the record is actually placed on the page. This event is too late to
add text that may need extra/less space (to shrink or grow), because
that's already been calculated. However the event is much less likely to
run multiple times (because a solution has already been plotted.) It can
run multiple times for the same record if the report's NextRecord property
is set to False.

Both events provide a counter for how many times it ran (the FormatCount
and PrintCount arguments), and there is also a Retreat event to indicate
that Access is back-tracking.

In general, use the Format event of the section to add text to an unbound
control, because it can then shrink or grow.

If you want to add text or graphics to a specific location on the page
(regardless of how the records are placed), use the Page event of the
report.

The report's Top property lets you know how far down the page this section
is falling, and you can read that in Format or Print. It is measured in
twips, where 1440 twips = 1 inch.

Do not use these events to programmatically accumulate totals over several
pages, nor to repeat the sections multiple times for some records. If the
user views/prints only some pages of the report, the events for the
skipped pages may not fire, so the totals/layout can be wrong.
 
Allen

Just a quick related question: Is there any possibility of the FormatCount
resets itself for the same instance of the Detail section?

Relevant details: (WinXP, Access2002, fully patched) I have a Report whose
RecordSource always has only one row / Record. In the Detail_Format
section, I use code to hide & resize & reposition Controls (including 11
SubReport Controls). I was trying to use the FormatCount to ensure that my
hiding / resizing / repositioning code is executed only once. However,
tracing the code show that my code was repeatedly executed but every time
the FormatCount is still shown as 1.

I eventually use a Static Variable to overcome this problem.
 
Did the Retreat event occur when the FormatCount was reset?

I haven't traced this through, Van, but it would be interesting to know if
Access restarts the FormatCount after a Retreat.
 
Allen

I was suspicious of the Retreat Event also but the Static Variable got me
out of trouble ...

I will be at th client office tomorrow. Will test the Retreat Event and let
you know whether the FormatCount is restarted by Retreat.
 
Allen

No, it is not the Retreat Event. The Retreat Event never fired.

In fact, the Retreat Event shouldn't fire the way I set up this Report
(1-row RecordSource). All Controls in the Detail Section have both
CanShrink and CanGrow set to False and I use code to hide, resize &
reposition all Controls (Labels, TextBoxes, PageBreaks, SubReports). If a
Label (+ its associated SubReport) doesn't fit on a page, the code make the
PageBreak Control (placed just above the Label) visible so that the Label (+
its associated SubReport) moves to the next page. Thus, Access should never
need to retreat.

When I tested my intCount (static variable increased each time the Format
Event is executed) vs FormatCount, I got:

intCount FormatCount
1 1
2 2
3 1
(Retreat never fired)

then the Report preview appeared ...

I'll do some most tests and see why the FormatCount is reset and post back
if I can find the cause ...
 
Allen

I did a bit more test today. Putting a break on the Exit Sub of the
Detail_Format Event and traced the code. After the Exit Sub, the execution
goes right back to the start of the Format Event but the FormatCount went 1,
2 and then back to 1.

I think I stick with my Static intCount for the moment until I can set some
other similar Reports and experiment more.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top